diff --git a/blog/feed.rss b/blog/feed.rss
index 753e03a..bb48cf5 100644
--- a/blog/feed.rss
+++ b/blog/feed.rss
@@ -2,37 +2,32 @@
blog // ~benhttps://tilde.team/~ben/blog/index.html
a blog about tildes and other thingsen
-Fri, 16 Nov 2018 12:06:53 -0500
-Fri, 16 Nov 2018 12:06:53 -0500
+Fri, 16 Nov 2018 23:22:08 -0500
+Fri, 16 Nov 2018 23:22:08 -0500
+weechat setup
+so you decided to switch from irssi to weechat?
+
+
what options do you need to set? what plugins? what scripts?
+
+
i'll go over some of the most essential of these, and share my full configs.
+
+
+]]>https://tilde.team/~ben/blog/weechat-setup.html
+https://tilde.team/~ben/blog/./weechat-setup.html
+~ben
+Fri, 16 Nov 2018 23:11:30 -0500
+
proactive redundancy
after the fiasco earlier this week, i've been taking steps to minimize
the impact if tilde.team were to go down. it's still a large spof (single-point-of-failure), but i'm reasonably certain that at least the irc net will remain up and functional in the event of another outage.
-
the first thing that i set up was a handful of additional ircd nodes: see the tilde.chat wiki for a full list. slash.tilde.chat is on my personal vps, and bsd.tilde.chat is hosted on the bsd vps that i set up for tilde.team.
-
-
i added the ipv4 addresses for these machines, along with the ip for yourtilde.com as A records for tilde.chat, creating a dns round-robin. host tilde.chat will return all four. requesting the dns record will return any one of them, rotating them in a semi-random fashion. this means that when connecting to tilde.chat on 6697 for irc, you might end up on any of {your,team,bsd,slash}.tilde.chat.
-
-
this creates the additional problem that visiting the tilde.chat site will end up at any of those 4 machines in much the same way. for the moment, the site is deployed on all of the boxes, making site setup issues hard to debug. the solution to this problem is to use a subdomain as the roundrobin host, as other networks like freenode do (see host chat.freenode.net for the list of servers).
-
-
i'm not sure how to make any of the other services more resilient. it's something that i have been and will continue to research moving forward.
-
-
the other main step that i have taken to prevent the same issue from happening again was to configure the firewall to drop outgoing requests to the subnets as defined in rfc 1918.
-
-
i'd like to consider at least this risk to be mitigated.
-
-
thanks for reading,
-
-
~ben
-
-
update: the round robin host is now irc.tilde.chat, which resolves the site issues that we were having, due to the duplicated deployments.
-
-
+
]]>https://tilde.team/~ben/blog/proactive-redundancy.html
https://tilde.team/~ben/blog/./proactive-redundancy.html~ben
@@ -47,32 +42,7 @@ november 13 post mortem
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
-
-
We have indications that there was an attack from your server.
-Please take all necessary measures to avoid this in the future and to solve the issue.
-
-
-
at this point, i have no idea what could have happened over night while i'm sleeping. the timestamp shows that it arrive only 30 minutes after i'd turned in for the night.
-
-
when i finally log on in the morning to check mails and irc mentions, i find that i'm unable to connect to tilde.team... strange, but ok; time to troubleshoot. i refresh the webmail to see what i'm missing. it ends up failing to find the server. even stranger! i'd better get the mails off my phone if they're on my @tilde.team mail!
-
-
here, i launch in to full debugging mode: what command was it? who ran it?
-
-
search ~/.bash_history per user was not very successful. nothing i could find was related to net or map. i had checked sudo grep nmap /home/*/.bash_history and many other commands.
-
-
at this point, i had connected with other ~teammates across other irc nets (#!, ~town, etc). among suggestions to check /var/log/syslog, /var/log/kern.log, and dmesg, i finally decided to check ps. ps -ef | grep nmap yielded nmap on an obscured uid and gid, which is shortly established to belong to a container i had provisioned for ~fosslinux.
-
-
i'm not considering methods of policing access to any site over port 80 and port 443. this is crazy. how do you police nmap when it isn't scanning on every port?
-
-
after a bit of shit-talking and reassurance from other sysadmins, i reexamined and realized that ~fosslinux had only run nmap for addresses in the 10.0.0.0/8 space. the 10/8 address space is intended to not be addressable outside the local space. how could hetzner have found out about a localhost network probe!?
-
-
finally, after speaking with more people than i expected to speak with in one day, i ended up sending three different support emails to hetzner support, which finally resulted in them unlocking the ip.
-
-
it's definitely time to research redundancy options!
after the fiasco earlier this week, i've been taking steps to minimize
the impact if tilde.team were to go down. it's still a large spof (single-point-of-failure), but i'm reasonably certain that at least the irc net will remain up and functional in the event of another outage.
-
the first thing that i set up was a handful of additional ircd nodes: see the tilde.chat wiki for a full list. slash.tilde.chat is on my personal vps, and bsd.tilde.chat is hosted on the bsd vps that i set up for tilde.team.
-
-
i added the ipv4 addresses for these machines, along with the ip for yourtilde.com as A records for tilde.chat, creating a dns round-robin. host tilde.chat will return all four. requesting the dns record will return any one of them, rotating them in a semi-random fashion. this means that when connecting to tilde.chat on 6697 for irc, you might end up on any of {your,team,bsd,slash}.tilde.chat.
-
-
this creates the additional problem that visiting the tilde.chat site will end up at any of those 4 machines in much the same way. for the moment, the site is deployed on all of the boxes, making site setup issues hard to debug. the solution to this problem is to use a subdomain as the roundrobin host, as other networks like freenode do (see host chat.freenode.net for the list of servers).
-
-
i'm not sure how to make any of the other services more resilient. it's something that i have been and will continue to research moving forward.
-
-
the other main step that i have taken to prevent the same issue from happening again was to configure the firewall to drop outgoing requests to the subnets as defined in rfc 1918.
-
-
i'd like to consider at least this risk to be mitigated.
-
-
thanks for reading,
-
-
~ben
-
-
update: the round robin host is now irc.tilde.chat, which resolves the site issues that we were having, due to the duplicated deployments.
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
-
-
We have indications that there was an attack from your server.
-Please take all necessary measures to avoid this in the future and to solve the issue.
-
-
-
at this point, i have no idea what could have happened over night while i'm sleeping. the timestamp shows that it arrive only 30 minutes after i'd turned in for the night.
-
-
when i finally log on in the morning to check mails and irc mentions, i find that i'm unable to connect to tilde.team... strange, but ok; time to troubleshoot. i refresh the webmail to see what i'm missing. it ends up failing to find the server. even stranger! i'd better get the mails off my phone if they're on my @tilde.team mail!
-
-
here, i launch in to full debugging mode: what command was it? who ran it?
-
-
search ~/.bash_history per user was not very successful. nothing i could find was related to net or map. i had checked sudo grep nmap /home/*/.bash_history and many other commands.
-
-
at this point, i had connected with other ~teammates across other irc nets (#!, ~town, etc). among suggestions to check /var/log/syslog, /var/log/kern.log, and dmesg, i finally decided to check ps. ps -ef | grep nmap yielded nmap on an obscured uid and gid, which is shortly established to belong to a container i had provisioned for ~fosslinux.
-
-
i'm not considering methods of policing access to any site over port 80 and port 443. this is crazy. how do you police nmap when it isn't scanning on every port?
-
-
after a bit of shit-talking and reassurance from other sysadmins, i reexamined and realized that ~fosslinux had only run nmap for addresses in the 10.0.0.0/8 space. the 10/8 address space is intended to not be addressable outside the local space. how could hetzner have found out about a localhost network probe!?
-
-
finally, after speaking with more people than i expected to speak with in one day, i ended up sending three different support emails to hetzner support, which finally resulted in them unlocking the ip.
-
-
it's definitely time to research redundancy options!
diff --git a/blog/november-13-post-mortem.html b/blog/november-13-post-mortem.html
index bbe739c..08278ed 100644
--- a/blog/november-13-post-mortem.html
+++ b/blog/november-13-post-mortem.html
@@ -40,6 +40,8 @@ november 13 post mortem
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
+
+
We have indications that there was an attack from your server.
Please take all necessary measures to avoid this in the future and to solve the issue.
@@ -64,7 +66,6 @@ Please take all necessary measures to avoid this in the future and to solve the
it's definitely time to research redundancy options!
diff --git a/blog/november-13-post-mortem.md b/blog/november-13-post-mortem.md
index 420a09e..55ee016 100644
--- a/blog/november-13-post-mortem.md
+++ b/blog/november-13-post-mortem.md
@@ -6,6 +6,8 @@ i awoke, not suspecting anything to be amiss. as soon as i logged in to check my
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
+---
+
> We have indications that there was an attack from your server.
> Please take all necessary measures to avoid this in the future and to solve the issue.
diff --git a/blog/proactive-redundancy.html b/blog/proactive-redundancy.html
index 456a365..8e57da7 100644
--- a/blog/proactive-redundancy.html
+++ b/blog/proactive-redundancy.html
@@ -37,6 +37,8 @@ proactive redundancy
after the fiasco earlier this week, i've been taking steps to minimize
the impact if tilde.team were to go down. it's still a large spof (single-point-of-failure), but i'm reasonably certain that at least the irc net will remain up and functional in the event of another outage.
+
+
the first thing that i set up was a handful of additional ircd nodes: see the tilde.chat wiki for a full list. slash.tilde.chat is on my personal vps, and bsd.tilde.chat is hosted on the bsd vps that i set up for tilde.team.
i added the ipv4 addresses for these machines, along with the ip for yourtilde.com as A records for tilde.chat, creating a dns round-robin. host tilde.chat will return all four. requesting the dns record will return any one of them, rotating them in a semi-random fashion. this means that when connecting to tilde.chat on 6697 for irc, you might end up on any of {your,team,bsd,slash}.tilde.chat.
@@ -56,7 +58,6 @@ the impact if tilde.team were to go down. it's still a large spof (single-point-
update: the round robin host is now irc.tilde.chat, which resolves the site issues that we were having, due to the duplicated deployments.
-
diff --git a/blog/proactive-redundancy.md b/blog/proactive-redundancy.md
index 5ed8e89..233b462 100644
--- a/blog/proactive-redundancy.md
+++ b/blog/proactive-redundancy.md
@@ -3,6 +3,8 @@ proactive redundancy
after the [fiasco](november-13-post-mortem.html) earlier this week, i've been taking steps to minimize
the impact if tilde.team were to go down. it's still a large spof (single-point-of-failure), but i'm reasonably certain that at least the irc net will remain up and functional in the event of another outage.
+---
+
the first thing that i set up was a handful of additional ircd nodes: see [the tilde.chat wiki](https://tilde.chat/wiki/?page=servers) for a full list. slash.tilde.chat is on my personal vps, and bsd.tilde.chat is hosted on the bsd vps that i set up for tilde.team.
i added the ipv4 addresses for these machines, along with the ip for yourtilde.com as A records for tilde.chat, creating a dns round-robin. `host tilde.chat` will return all four. requesting the dns record will return any one of them, rotating them in a semi-random fashion. this means that when connecting to tilde.chat on 6697 for irc, you might end up on any of `{your,team,bsd,slash}.tilde.chat`.
diff --git a/blog/tag_irc.html b/blog/tag_irc.html
new file mode 100644
index 0000000..4abdbf8
--- /dev/null
+++ b/blog/tag_irc.html
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+blog // ~ben — posts tagged "irc"
+
+
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
-
-
We have indications that there was an attack from your server.
-Please take all necessary measures to avoid this in the future and to solve the issue.
-
-
-
at this point, i have no idea what could have happened over night while i'm sleeping. the timestamp shows that it arrive only 30 minutes after i'd turned in for the night.
-
-
when i finally log on in the morning to check mails and irc mentions, i find that i'm unable to connect to tilde.team... strange, but ok; time to troubleshoot. i refresh the webmail to see what i'm missing. it ends up failing to find the server. even stranger! i'd better get the mails off my phone if they're on my @tilde.team mail!
-
-
here, i launch in to full debugging mode: what command was it? who ran it?
-
-
search ~/.bash_history per user was not very successful. nothing i could find was related to net or map. i had checked sudo grep nmap /home/*/.bash_history and many other commands.
-
-
at this point, i had connected with other ~teammates across other irc nets (#!, ~town, etc). among suggestions to check /var/log/syslog, /var/log/kern.log, and dmesg, i finally decided to check ps. ps -ef | grep nmap yielded nmap on an obscured uid and gid, which is shortly established to belong to a container i had provisioned for ~fosslinux.
-
-
i'm not considering methods of policing access to any site over port 80 and port 443. this is crazy. how do you police nmap when it isn't scanning on every port?
-
-
after a bit of shit-talking and reassurance from other sysadmins, i reexamined and realized that ~fosslinux had only run nmap for addresses in the 10.0.0.0/8 space. the 10/8 address space is intended to not be addressable outside the local space. how could hetzner have found out about a localhost network probe!?
-
-
finally, after speaking with more people than i expected to speak with in one day, i ended up sending three different support emails to hetzner support, which finally resulted in them unlocking the ip.
-
-
it's definitely time to research redundancy options!
diff --git a/blog/tag_post-mortem.html b/blog/tag_post-mortem.html
index b8a4ef2..ff0d2c8 100644
--- a/blog/tag_post-mortem.html
+++ b/blog/tag_post-mortem.html
@@ -39,32 +39,7 @@ november 13 post mortem
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
-
-
We have indications that there was an attack from your server.
-Please take all necessary measures to avoid this in the future and to solve the issue.
-
-
-
at this point, i have no idea what could have happened over night while i'm sleeping. the timestamp shows that it arrive only 30 minutes after i'd turned in for the night.
-
-
when i finally log on in the morning to check mails and irc mentions, i find that i'm unable to connect to tilde.team... strange, but ok; time to troubleshoot. i refresh the webmail to see what i'm missing. it ends up failing to find the server. even stranger! i'd better get the mails off my phone if they're on my @tilde.team mail!
-
-
here, i launch in to full debugging mode: what command was it? who ran it?
-
-
search ~/.bash_history per user was not very successful. nothing i could find was related to net or map. i had checked sudo grep nmap /home/*/.bash_history and many other commands.
-
-
at this point, i had connected with other ~teammates across other irc nets (#!, ~town, etc). among suggestions to check /var/log/syslog, /var/log/kern.log, and dmesg, i finally decided to check ps. ps -ef | grep nmap yielded nmap on an obscured uid and gid, which is shortly established to belong to a container i had provisioned for ~fosslinux.
-
-
i'm not considering methods of policing access to any site over port 80 and port 443. this is crazy. how do you police nmap when it isn't scanning on every port?
-
-
after a bit of shit-talking and reassurance from other sysadmins, i reexamined and realized that ~fosslinux had only run nmap for addresses in the 10.0.0.0/8 space. the 10/8 address space is intended to not be addressable outside the local space. how could hetzner have found out about a localhost network probe!?
-
-
finally, after speaking with more people than i expected to speak with in one day, i ended up sending three different support emails to hetzner support, which finally resulted in them unlocking the ip.
-
-
it's definitely time to research redundancy options!
after the fiasco earlier this week, i've been taking steps to minimize
the impact if tilde.team were to go down. it's still a large spof (single-point-of-failure), but i'm reasonably certain that at least the irc net will remain up and functional in the event of another outage.
-
the first thing that i set up was a handful of additional ircd nodes: see the tilde.chat wiki for a full list. slash.tilde.chat is on my personal vps, and bsd.tilde.chat is hosted on the bsd vps that i set up for tilde.team.
-
-
i added the ipv4 addresses for these machines, along with the ip for yourtilde.com as A records for tilde.chat, creating a dns round-robin. host tilde.chat will return all four. requesting the dns record will return any one of them, rotating them in a semi-random fashion. this means that when connecting to tilde.chat on 6697 for irc, you might end up on any of {your,team,bsd,slash}.tilde.chat.
-
-
this creates the additional problem that visiting the tilde.chat site will end up at any of those 4 machines in much the same way. for the moment, the site is deployed on all of the boxes, making site setup issues hard to debug. the solution to this problem is to use a subdomain as the roundrobin host, as other networks like freenode do (see host chat.freenode.net for the list of servers).
-
-
i'm not sure how to make any of the other services more resilient. it's something that i have been and will continue to research moving forward.
-
-
the other main step that i have taken to prevent the same issue from happening again was to configure the firewall to drop outgoing requests to the subnets as defined in rfc 1918.
-
-
i'd like to consider at least this risk to be mitigated.
-
-
thanks for reading,
-
-
~ben
-
-
update: the round robin host is now irc.tilde.chat, which resolves the site issues that we were having, due to the duplicated deployments.
tilde.team was at the least inaccessible, and at the worst, down completely. according the message in my inbox, there hade been an attempted "attack" from my IP.
-
-
We have indications that there was an attack from your server.
-Please take all necessary measures to avoid this in the future and to solve the issue.
-
-
-
at this point, i have no idea what could have happened over night while i'm sleeping. the timestamp shows that it arrive only 30 minutes after i'd turned in for the night.
-
-
when i finally log on in the morning to check mails and irc mentions, i find that i'm unable to connect to tilde.team... strange, but ok; time to troubleshoot. i refresh the webmail to see what i'm missing. it ends up failing to find the server. even stranger! i'd better get the mails off my phone if they're on my @tilde.team mail!
-
-
here, i launch in to full debugging mode: what command was it? who ran it?
-
-
search ~/.bash_history per user was not very successful. nothing i could find was related to net or map. i had checked sudo grep nmap /home/*/.bash_history and many other commands.
-
-
at this point, i had connected with other ~teammates across other irc nets (#!, ~town, etc). among suggestions to check /var/log/syslog, /var/log/kern.log, and dmesg, i finally decided to check ps. ps -ef | grep nmap yielded nmap on an obscured uid and gid, which is shortly established to belong to a container i had provisioned for ~fosslinux.
-
-
i'm not considering methods of policing access to any site over port 80 and port 443. this is crazy. how do you police nmap when it isn't scanning on every port?
-
-
after a bit of shit-talking and reassurance from other sysadmins, i reexamined and realized that ~fosslinux had only run nmap for addresses in the 10.0.0.0/8 space. the 10/8 address space is intended to not be addressable outside the local space. how could hetzner have found out about a localhost network probe!?
-
-
finally, after speaking with more people than i expected to speak with in one day, i ended up sending three different support emails to hetzner support, which finally resulted in them unlocking the ip.
-
-
it's definitely time to research redundancy options!
after the fiasco earlier this week, i've been taking steps to minimize
the impact if tilde.team were to go down. it's still a large spof (single-point-of-failure), but i'm reasonably certain that at least the irc net will remain up and functional in the event of another outage.
-
the first thing that i set up was a handful of additional ircd nodes: see the tilde.chat wiki for a full list. slash.tilde.chat is on my personal vps, and bsd.tilde.chat is hosted on the bsd vps that i set up for tilde.team.
-
-
i added the ipv4 addresses for these machines, along with the ip for yourtilde.com as A records for tilde.chat, creating a dns round-robin. host tilde.chat will return all four. requesting the dns record will return any one of them, rotating them in a semi-random fashion. this means that when connecting to tilde.chat on 6697 for irc, you might end up on any of {your,team,bsd,slash}.tilde.chat.
-
-
this creates the additional problem that visiting the tilde.chat site will end up at any of those 4 machines in much the same way. for the moment, the site is deployed on all of the boxes, making site setup issues hard to debug. the solution to this problem is to use a subdomain as the roundrobin host, as other networks like freenode do (see host chat.freenode.net for the list of servers).
-
-
i'm not sure how to make any of the other services more resilient. it's something that i have been and will continue to research moving forward.
-
-
the other main step that i have taken to prevent the same issue from happening again was to configure the firewall to drop outgoing requests to the subnets as defined in rfc 1918.
-
-
i'd like to consider at least this risk to be mitigated.
-
-
thanks for reading,
-
-
~ben
-
-
update: the round robin host is now irc.tilde.chat, which resolves the site issues that we were having, due to the duplicated deployments.
what options do you need to set? what plugins? what scripts?
+
+
i'll go over some of the most essential of these, and share my full configs.
+
+
+
+
options
+
+
+
logger.level.irc the default is 9, which includes joins and parts. in most cases you can set this to 3, which only includes messages
+
weechat.look.buffer_notify.default the default here is "all", which will add joins and parts to your hotlist. set it to "message".
+
weechat.look.confirm_quit set this to on. you'll thank me when you type /quit and mean /close
+
weechat.look.highlight add a comma-separated list of names/terms you'd like to trigger a highlight here
+
weechat.look.prefix_align_max set this to something between 10 and 20. otherwise, long nicks will crush your available screen real estate.
+
buflist.format.indent try something like ${color:237}${if:${buffer.next_buffer.local_variables.type}=~^(channel|private)$?├:└}
+
buflist.format.number if you want to skip the . or space after the number, set it to ${color:green}${number}
+
irc.look.color_nicks_in_names set this to on
+
irc.look.color_nicks_in_nicklist set this to on
+
irc.look.server_buffer set this to independent to prevent automatic merges with the core weechat buffer. especially useful if you plan on using autosort.py
+
irc.server_default.autoconnect set this to on so you don't have to set it for every new network you add.
+
+
+
scripts
+
+
these scripts can be managed with the built in /script tool. press i, then enter on the selected script to install it.
+
+
+
highmon.pl - set aside a buffer to list the places your nick has been mentioned
go.py - fuzzy quick jump by buffer number of channel name
+
autojoin.py - use /autojoin --run to save all the channels you're currently in to be autojoined the next time you start weechat
+
autosort.py - use this script in tandem with irc.look.server_buffer=independent to keep you channel and server list in order
+
colorize_lines.pl - i use this script to highlight the entire line of messages i've been mentioned in. check the options in the source or with /help colorize_lines
+
grep.py - quickly search history and buffers with /grep
+
+
+
plugins
+
+
plugins include the likes of weechat-slack and the irc plugin.
+
+
unless you need slack support, you should be ok without additional plugins
+
+
diff --git a/blog/weechat-setup.md b/blog/weechat-setup.md
new file mode 100644
index 0000000..8837a95
--- /dev/null
+++ b/blog/weechat-setup.md
@@ -0,0 +1,69 @@
+weechat setup
+
+so you decided to switch from irssi to weechat?
+
+what options do you need to set? what plugins? what scripts?
+
+i'll go over some of the most essential of these, and share my full configs.
+
+---
+
+### options
+
+* `logger.level.irc` the default is 9, which includes joins and parts. in most cases you can set this to 3, which only includes messages
+* `weechat.look.buffer_notify.default` the default here is "all", which will add joins and parts to your hotlist. set it to "message".
+* `weechat.look.confirm_quit` set this to on. you'll thank me when you type `/quit` and mean `/close`
+* `weechat.look.highlight` add a comma-separated list of names/terms you'd like to trigger a highlight here
+* `weechat.look.prefix_align_max` set this to something between 10 and 20. otherwise, long nicks will crush your available screen real estate.
+* `buflist.format.indent` try something like `${color:237}${if:${buffer.next_buffer.local_variables.type}=~^(channel|private)$?├:└}`
+* `buflist.format.number` if you want to skip the . or space after the number, set it to `${color:green}${number}`
+* `irc.look.color_nicks_in_names` set this to on
+* `irc.look.color_nicks_in_nicklist` set this to on
+* `irc.look.server_buffer` set this to independent to prevent automatic merges with the core weechat buffer. especially useful if you plan on using [autosort.py](https://weechat.org/scripts/source/autosort.py.html/)
+* `irc.server_default.autoconnect` set this to on so you don't have to set it for every new network you add.
+
+
+### scripts
+
+these scripts can be managed with the built in `/script` tool. press i, then enter on the selected script to install it.
+
+* [highmon.pl](https://weechat.org/scripts/source/highmon.pl.html/) - set aside a buffer to list the places your nick has been mentioned
+* [colorize_nicks.py](https://weechat.org/scripts/source/colorize_nicks.py.html/) - show nicks in chat with colors
+* [go.py](https://weechat.org/scripts/source/go.py.html/) - fuzzy quick jump by buffer number of channel name
+* [autojoin.py](https://weechat.org/scripts/source/autojoin.py.html/) - use `/autojoin --run` to save all the channels you're currently in to be autojoined the next time you start weechat
+* [autosort.py](https://weechat.org/scripts/source/autosort.py.html/) - use this script in tandem with irc.look.server_buffer=independent to keep you channel and server list in order
+* [colorize_lines.pl](https://weechat.org/scripts/source/colorize_lines.pl.html/) - i use this script to highlight the entire line of messages i've been mentioned in. check the options in the source or with `/help colorize_lines`
+* [grep.py](https://weechat.org/scripts/source/grep.py.html/) - quickly search history and buffers with `/grep`
+
+
+### plugins
+
+plugins include the likes of [weechat-slack](https://github.com/wee-slack/wee-slack) and the irc plugin.
+
+unless you need slack support, you should be ok without additional plugins
+
+
+### the rest of my configs
+
+you can find the rest of my configs [here](https://tildegit.org/ben/dotfiles/src/branch/master/weechat/.weechat).
+
+if you have any questions, feel free to ping me on irc. i'm benharri on freenode and ben on [tilde.chat](https://tilde.chat)
+
+
+### screenshot
+
+here's a screenshot of my current configs
+
+
+
+
+### bonus
+
+if you have an existing setup, you can check the config changes you've made with `/set diff`
+
+additionally, feel free to [use my .gitignore](https://tildegit.org/ben/dotfiles/src/branch/master/weechat/.weechat/.gitignore), add your ~/.weechat to source control, and compare.
+
+hope you've enjoyed customizing your weechat!
+
+
+tags: irc, linux, weechat
