Since I forgot to branch the original source, the branching looked awesomely crappy. Therefore I decided to rebase entire thing to ease up keeping track with Moebooru “mainline”. All my commits are now in branch “default”. If you didn’t do any change, backout up to revision 9174b6b5b02d and then pull again. And then, don’t ever touch moe branch again anymore.
Let’s revisit the plan:
- Upgrade to Ruby 1.9: done, need testing.
- Update all plugins: mostly done, can use some trimming.
- Update anything deprecated: nope
- Migrate to Bundler: done, not sure how to test.
- Use RMagick instead of custom ruby-gd plugin: nope
- Use RMagick instead of calling jhead binary: nope
- And more!: I hope you didn’t expect me to do more while there are incomplete items above.
Sure looks good. Need more testing though. There’s also one part which I totally had no idea why should be changed when upgrading to 1.9. Just grep for FIXME to see which it is and hopefully fix it up for me (or explain what it does).
As usual, having completed the work for today, live demo is up and open for everyone to break (…if there’s anyone, that is).
WARNING: using method below will lock yourself out when using emergency console since whatever crypt it’s using surely doesn’t understand bcrypt (as I experienced myself). Additionally, this solution won’t add bcrypt support to other applications using crypt interface like proftpd unless it’s started by preloading libxcrypt.so first (also from my own experience).
As much as Drepper want to pretend
bcrypt is wrong solution, it actually gives one benefit: ease of switch to Linux. Some systems use
bcrypt by default or configurable to use it. On other case, there might be time where you need system’s (or applications using system’s)
crypt to handle
bcrypt passwords from external system (usually web applications).
It’s quite difficult to enable bcrypt support in RHEL based distro as there is no
pam_unix2 packages available. Thankfully it’s available in Debian (and derivatives) in package
The README.Debian says to modify files in
/etc/pam.d but if I remember it correctly, it confused apt PAM handling system or whatever. Fast forward few weeks, I discovered a better way to use it by creating PAM configuration in
/usr/share/pam-configs. Since it’s mostly equivalent to normal
pam_unix, I just copy and modify the file using this (long-ass) oneliner sed:
sed -e 's/pam_unix.so/pam_unix2.so/g;s/^Name: Unix authentication$/Name: Unix2 authentication/;s/pam_unix2.so obscure sha512/pam_unix2.so obscure blowfish rounds=8/;s/ nullok_secure//' /usr/share/pam-configs/unix > /usr/share/pam-configs/unix2
pam-auth-update, select Unix2 authentication and deselect Unix authentication. Don’t forget to update passwords for all other users as well or they won’t be able to login since
pam_unix2 doesn’t recognize sha based hashes.
Actually, change all other users password to use md5 first before replacing the PAM with
Update 2012-04-01: Removed
nullok_secure since it isn’t supported.
Update 2012-06-09: Added warning.
Don’t get tricked by the “release” system. Apart of the base system, FreeBSD perfectly qualifies as rolling release. I guess it’s also why the binary package management sucked so badly. You won’t find how to upgrade certain packages using binary method in their Ports’ UPDATING page.
Here’s the example:
20120225: AFFECTS: users of archivers/libarchive AUTHOR: glewis@FreeBSD.org libarchive has been updated to version 3.0.3, with a shared library bump. This requires dependent ports to be rebuilt. # portmaster -r libarchive or # portupgrade -r archivers/libarchive
You would think the dependent packages got version bump to ensure their proper dependency – but they didn’t. Instead you had to recompile everything depending on it.
And then there’s another case:
20120220: AFFECTS: users of graphics/libungif AUTHOR: dinoex@FreeBSD.org libungif is obsolete, please deinstall it and rebuild all ports using it with graphics/giflib. # portmaster -o graphics/giflib graphics/libungif # portmaster -r giflib or # portupgrade -o graphics/giflib graphics/libungif # portupgrade -rf giflib
Of course, ArchLinux kind of managed to do it but that’s a purely binary rolling release Linux distro. The maintainer worked hard to ensure such kind of thing get handled properly by all their users which mostly use binary packages. FreeBSD on other hand tried to claim capable of both but it really isn’t (unless I missed something).
I’m intending to contact pkgng creator to ask his opinion about this but have yet to do it…
I’m not sure which sound cards are exhibiting this problem but at least it is in my system (onboard Realtek HD – Intel DH61BE motherboard running Windows 7 x64). It’s been annoying me since like forever and finally tonight I decided to actually solve the problem.
As it turns out, the solution is quite simple: disable PC Beep channel. A quick google showed this hit quite a bit of people and apparently this is the reason (or at least related).
On related note, apparently I’ve did this before and then completely forgotten. This is why I wrote it this time.
If you didn’t know, the current moebooru running on oreno.imouto is using ancient version of many things. It also uses a custom lighty module (mod_zipfile) which doesn’t seem to be available anywhere.
I’ve updated it with latest Rails 2.x and made it compatible with nginx. Mostly. You can see it running here.
- Upgrade to Ruby 1.9.
- Update all plugins.
- Update anything deprecated.
- Migrate to Bundler.
- Use RMagick instead of custom ruby-gd plugin.
- Use RMagick instead of calling jhead binary.
- And more!
During my migration to other server, I recreated some of my configs and enabled gzip compression for most file types. Here’s the relevant config:
It should cover most text-based content one will ever serve over the web. Probably.