The planned services upgrade and database prune went ahead today as planned and has completed successfully. Approximately 300000 nicks were removed from the database, and we’ve moved to Atheme 7, so hopefully response times from services should be improved, with less of the lag that was sometimes noticeable before.
In addition, certificate based authentication is now available. We’ll hopefully get the docs for this up online shortly.
Hi
The long-awaited upgrade of services which we blogged about a while ago is now planned for this coming weekend, the 16th/17th June.
We anticipate up to an hour of services outage for this upgrade and prune to take place. We will notify the connected users closer to the time through the use of WALLOPS and/or globals, but please do plan ahead accordingly for a period of services unavailability.
We will be moving to Atheme 7, so, amongst other improvements, this will see the introduction of certificate-based authentication to services.
To use certificate based authentication, you would need firstly to generate a certificate, then add the certificate to your client, then tell nickserv about your certificate fingerprint. We’ll explain more about this in a future blog entry or on the freenode website in the near future.
Every couple of years, freenode likes to get out the shears and prune the services database. Recently we broke the 80,000 usercount barrier, but the services stats are way ahead:
Sat 13:35:46 -OperServ(OperServ@services.)- Registered accounts: 446777
Sat 13:35:46 -OperServ(OperServ@services.)- Registered nicknames: 557497
Sat 13:35:47 -OperServ(OperServ@services.)- Registered channels: 141373
We’ve noticed that nearly half of the accounts shown there haven’t been used in the past 6 months! More importantly, over the past few months many people have noticed significant waits when issuing certain services commands – and we’d like to fix that.
Hopefully, the services upgrade should help with this, but we’re going to coincide this with a database prune.
As of the services upgrade date, any nicks unused for > 150 days are at risk of being dropped. This includes grouped nicks. The easy way to avoid this happening is to use each of your grouped nicks (while identified to the appropriate account) within the next few weeks – and to drop those that you don’t need anymore!
The testnet (testnet.freenode.net, port 9002. 9003 for SSL) is running a database snapshot from mid-March and will be periodically updated from the production network. This database instance is being regularly pruned – so check there to see how your account will be affected (use /msg nickserv info on both the production and test networks to see the differences).
Remember that testnet isn’t running a real-time duplicate of the production network, so when you use nicks which would be expired on the production network, they will still appear expired on testnet until the next database snapshot is migrated. Don’t worry though – the actual pruning will only occur on the current database at the time of upgrade.
On which note.. an upgrade date hasn’t been formally fixed but we’re aiming for mid-May.
Thanks, and don’t forget to test the testnet!
Very soon we will be upgrading your favourite network helpers… (no not erry…): NickServ, ChanServ, Alis etc. They’re currently connected to our testnet and we need your help with testing, looking for any issues which may affect the production network.
You can connect to our testnet at testnet.freenode.net port 9002 (or 9003 for SSL)
The full changelog is rather long and not all of the features offered by atheme are loaded on freenode. So to help you out, we’ve pulled out the highlights which we think deserve attention:
Please note that the services database on the testnet is probably more than a few days old. Don’t be surprised if recent changes you have made on the production network aren’t replicated there.
We’re all in in #freenode on the testnet so please come find us there if you have any questions or bugs.
Finally, look out for a followup blogpost (hopefully quite soon) with some important information on the upgrade itself and our planned database cleanup!
Thanks for using freenode!
P.s. a full list of changes from atheme ~5.1 to ~6 can be found here
We’ve got some ircd upgrades in the works!
You may remember several weeks ago that we upgraded our ircd on the production network. Since then, we’ve wanted to fine-tune some changes and make sure that the upgrade is more consistent with the old version.
Over the next few weeks, we’ll be looking to perform upgrades on the production network again. This will mean every server will reboot. A programme for the upgrades can be found at the end of this post (updated 13th Nov 2011).
In the meantime, please continue to help us to test the ircd at testnet.freenode.net port 9002 or 9003 for SSL (if you don’t get onto the first server that the DNS roundrobin gives you, keep trying!). Look for anything broken, inconsistent with previous versions (especially in terms of information release) or illogical. If serious issues are reported, we’ll aim to fix before upgrading, rather than having a further later upgrade. Please report issues to #freenode-seven on the production network.
Thanks!
NB: this list does not include servers invisible to users (eg hubs).
Week 1: Sun 13th Nov
-!- kornbluth.freenode.net Frankfurt, Germany
-!- zelazny.freenode.net Corvallis, OR, USA
-!- stross.freenode.net Corvallis, OR, USA (webchat backup)
Week 2: Sun 20th Nov
-!- barjavel.freenode.net Paris, FR
-!- wolfe.freenode.net Manchester, England
-!- hubbard.freenode.net Pittsburgh, PA, US
Week 3: Sun 27th Nov
-!- adams.freenode.net Budapest, HU, EU
-!- holmes.freenode.net London, UK
-!- sendak.freenode.net Vilnius, Lithuania, EU
-!- rowling.freenode.net Corvallis, OR, USA (webchat)
Week 4: Sun 4th Dec
-!- pratchett.freenode.net Rennes, France
-!- calvino.freenode.net Milan, IT
-!- leguin.freenode.net Ume?, SE, EU
-!- niven.freenode.net Corvallis, OR, USA
Week 5: Sun 11th Dec
-!- hitchcock.freenode.net Sofia, BG, EU
-!- gibson.freenode.net Oslo, Norway
-!- card.freenode.net Washington, DC, USA
-!- asimov.freenode.net TX, USA
-!- verne.freenode.net Newark, NJ, US
Unscheduled.
-!- roddenberry.freenode.net
-!- bartol.freenode.net
-!- brown.freenode.net
-!- anthony.freenode.net
Update: all upgrades are now complete.
Unfortunately, it seems the box our webchat is on has decided to fall out with the Internet again. We’re working on setting up a reserve instance which shouldn’t be affected by this sort of issue in the future. When we have more details, we’ll update this post. We’re really sorry for the inconvenience this causes, and guarantee it will be less in future.
Update: The host’s issues appear to have been resolved. We now also have a backup instance running which can easily be switched to in the event of downtime in the future.
Hi everyone.
Currently the freenode webchat instance (webchat.freenode.net) is down. This is due to maintenance by the host of the box upon which the service sits, and looks set to continue for up to a further 6 hours.
This is maintenance that we, as staff, were not previously aware of.
We’re very sorry for the inconvenience and are doing what we can to reduce it.
Update: resolved.
Webchat has always presented an interesting problem, mostly for the staff of various channels as well as the network itself, but indirectly for all our users as well. All webchat connections come from the IP address of the webchat service. This results in them having to be handled a little bit differently from other connections.
To begin with, there needs to be a way for network or channel staff to identify individual connections, as well as where they originated from. The way this has previously been handled is by encoding the IP of the source (the IP someone uses to connect to the webchat) in hexadecimal form in the ident field of the user. The webchat users are “cloaked” (that is, their real hostname, which would be that of the webchat server, is replaced) with a unique string identifying the connection. This method allows channel staff to ban or quiet a webchat user via the unique connection string, or via the ident information.
While this works, it’s confusing to many. The unique connection string changes every time a user makes a new connection through webchat. Therefore, we’ve changed how we do the cloaking so IPs are shown in cloaks. This makes it much simpler for channel staff to see what is going on, and who is who. For now, this change only applies to those using the freenode webchat at http://webchat.freenode.net. The effect is to change a cloak of the form “gateway/web/freenode/x-iiqzrxiqfnnglqji” to the form “gateway/web/freenode/ip.171.205.239.16“.
We would like to point out that this does not in any way reduce the privacy of users of webchat: it has always been possible for anyone to directly convert the encoded ident string back to an IP address. In addition, the real hostnames of clients have always been visible unencoded in the “whois” output for the user.
In addition, we have made a small but potentially significant change to how the “ident” is shown. This has become necessary so that, with future versions of our ircd, we can properly limit connections per IP address via webchat. For a typical freenode webchat user, the full hostmask previously had the form “~abcdef1@gateway/web/freenode/...“. Many historical webchat bans and quiets are set as “*!~abcdef1@gateway/web/freenode/*“. The change that we are making will break these bans. We have removed the ~ from the ident for all webchat connections (not just freenode’s webchat), giving a full mask of the form “abcdef1@gateway/web/freenode/ip.171.205.239.16“.
As such, channel ops are advised to adjust their bans into the form of either “*!abcdef1@gateway/web/freenode/*” or “*!*@gateway/web/freenode/ip.171.205.239.16” as soon as possible.
A further result of this change is that those hosts from which a large number of legitimate users connect to freenode through the webchat service may suffer refused connections due to breaching the limits. If you find youself faced by an error of the form “Too many connections”, please email iline at freenode dot net with details of the IP address affected (which can be obtained from www.whatismyip.org), the name of the organisation, and the number of connections expected, so that we can place a limit exemption. Please note that if you have a message of the form “Gateway connections are currently blocked” or “Gateway connections are currently being throttled”, this is a different matter for which an I:line cannot help.
We hope that these changes make connections through the freenode webchat easier to manage for channel ops and more transparent for all users.
After much time in development and testing, the move to ircd-seven is finally complete. The migration took place in the early hours of today, Saturday January 30th 2010.
I would like to express thanks to everyone who has helped us get here — those staff and users who have helped find and squash bugs, those who have done extensive load testing and those who have helped finalising documentation in preparation for the migration earlier today.
In particular I would like to thank the Charybdis development team and the ratbox contributors whose work left us with a brilliant ircd platform to build upon to create the more freenode specific ircd-seven. In no particular order my thanks go to:
dwr, Valery Yatsko <dwr -at- shadowircd.net>
gxti, Michael Tharp <gxti -at- partiallystapled.com>
jilles, Jilles Tjoelker <jilles -at- stack.nl>
nenolod, William Pitcock <nenolod -at- nenolod.net>
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
anfl, Lee Hardy <lee -at- leeh.co.uk>
beu, Elfyn McBratney <elfyn.mcbratney -at- gmail.com>
Entrope, Michael Poole <mdpoole -at- trolius.org>
ThaPrince, Jon Christopherson <jon -at- vile.com>
twincest, River Tarnell <river -at- attenuate.org>
w00t, Robin Burchell <surreal.w00t -at- gmail.com>
And for leading the development efforts of ircd-seven, for putting up with my many quirky and often unreasonable requests:
spb, Stephen Bennett <stephen -at- freenode.net>
I’d also like to express my gratitude to the following freenode volunteers for the hard work they’ve put in to make the migration go as smoothly as possible. I’ve been amazed at the initiative and responsibility shown in this last phase. Your help has been invaluable and I feel privileged to work with you:
kloeri, Bryan Østergaard
Lorez, Mike Mattice
Martinp23, Martin Peeks
Md, Marco D’Itri
With the exception of port(s) 7000 and 7070 which are now being used for SSL, all other ports and DNS stay the same as it did prior to migration.
If you are a regular freenode user you will most likely be aware that there’s some user facing changes with the move to ircd-seven (and likely to have been annoyed by my global notices on the subject), you may wish to familiarise yourself with the updated FAQ and glance at some of these earlier ircd-seven related blog posts:
http://blog.freenode.net/2010/01/connecting-to-freenode-using-tor-sasl/
http://blog.freenode.net/2008/11/help-us-test-ircd-seven/
http://blog.freenode.net/2010/01/migration-to-new-ircd/
http://blog.freenode.net/2010/01/ircd-migration…-jan-30th-2010/
Again, thank you for helping out, however small or large your contribution may have been. We are celebrating the migration to ircd-seven with a special fundraiser “Give £7 for seven”. This campaign will end on February 7th 2010, until such time you may read more and donate here. Any donation of £21 or any multiple of £7 over £21 will receive a freenode t-shirt.
To all our users, thank you for using the network, and welcome to seven!
With our change of ircd to the all new ircd-seven, we are trialling a new method of allowing users to connect to the network via Tor. This method brings a number of changes:
We have collected together scripts for irssi and mirc, while Conspire supports SASL natively. Scripts may be available for other clients in addition.
Download and install this script (cap_sasl.pl) and, after loading it, configure it using
/sasl set <network> <username> <password> <mechanism>
Supported mechanisms are PLAIN and DH-BLOWFISH.
A mirc script is available, taken from a forum post by Kyle Travaglini. You can retrieve the source here.
Instructions (adapted from that forum):
If you have any problems, either pop into #freenode from a non-torified connection or drop an email to support AT freenode.net.
This method of connecting to freenode using Tor supersedes all previous methods, including Tor-GPG. We hope that this method of connecting via Tor will help to make it somewhat more accessible to you!