So, opened up the #slackware home server for a very needed deep cleaning.
I was pleasantly surprised to see it was not too dusty.
I am really happy that this little Intel Atom machine is still working after all these years, and Slackware always performed perfectly on it.
It has been through a system disk change, from a Toshiba (?) HDD to a Crucial SSD, a change of power supply and provides access from the outside into the house LAN, including my Kallithea repo manager.
It also provides a central point for various backups, some additional services and various RSS stuff.
Uptime was up to 300 days until I powered it off in June.
Now, I am sure one of the BSDs would also have done a great job on this little machine, but, hey, I am a slacker!
Now, time to upgrade to Slackware 15 my old friend! ๐ค
Drat, sometimes the old school tools are the best tools...
The Gnome disk utility gets all mixed up on the disk partition of the installation USB key while 'fdisk' will happily delete everything and recreate an empty partition.
The OpenSUSE installation tools does not know what a #Slackware
ISO image is, while 'dd' will happily write it to the USB key. Now waiting for it to finish...
Fear not, gentle reader, as that poor little penguin's head was properly reformatted, with the installation proceeding without major issues...
The only problem was that the default kernel was not outputting anything to the VGA, selecting the "graphical" version solved that issue, at the price of a couple of resets.
Ah yes, the joys of updating a new #Slackware machine, 'slackpkg update' and 'slackpkg upgrade-all' will take care of it, but let's just say there is A LOT of stuff to update...
So, today:
- my re-installed home server runs perfectly stable, Yay! ๐
- links needs... all of X11 to run? Booo! ๐คฏ
I mean take look at this:
slackpkg install pixman
slackpkg install libxcb libXau libegl
slackpkg install libxdcmp libglvnd
slackpkg install libXrender libXdmcp
slackpkg install libXext
slackpkg install fontconfig
slackpkg install x11-skel x11-ssh-askpass x11perf
slackpkg install libX11
All of this for a term app? Seriously?
- There is an update for dovecot, just sayin'
Compiling OSSEC 3.7.0 under #Slackware 15 requires you to edit the Makefile and change:
USE_SYSTEMD?=yes
to USE_SYSTEMD?=no
Because, of course, systemd. ๐คฆโโ๏ธ
"Starting with ClamAV v0.105, a Rust toolchain is required to compile portions of libclamav."
Fortunately, Rust has been packaged for #Slackware 15 ๐ค
"configure" is done, "make" is running... ๐ค
Why do people complicate things needlessly is beyond me. ClamAV used to be entirely C, now they are mixing C and Rust , with predictable results.
Do the right thing and reprogram the entire thing in Rust if you want to be hip, but don't mix things like that, you are just making things harder for everyone, you included!
All right dinner is done now back to our ongoing series: let's put the house server together!
Tonight: torrent clients.
- Transmission is now CMake only with predictable results: I cannot compile the latest version... And the CMake error message is weird indeed. More investigations required.
- rtorrent requires libtorrent, which requires 'boost' - not an issue since boost is a standard package in Slackware. EXCEPT it also requires 'b2' which is not available on #Slackware
Transmission is now installed and running. Thanks again to @m0xee for suggesting version 0.4.5! That compiled right out of the box.
Regarding rtorrent, I am an idiot, because the 'libtorrent' it wants is the one from the author of rtorrent, and not the one you get from libtorrent.org ... Which is the one I installed in the first place... ๐คฆโโ๏ธ
Regarding 'b2' - to install it on Slackware: download boost, go to tools/build and enter:
./bootstrap.sh
sudo ./b2 install --prefix=/usr/local/
@ParadeGrotesque
Ha-ha-ha-ha! Yes, those are different, names libtorrent and libtorrent-rasterbar are often used to distinguish the two.
Another thing that might be of interest: I've seen opinions on Transmission's issue tracker that while 4.0 branch might be lighter on CPU and RAM usage, it could be heavier on disk I/O and indeed, on old PowerPC MacMini with "spinning rust" storage that hosts transmission-daemon for me, I often observe low CPU load, but system being in "waiting for I/O" state.
@ParadeGrotesque
Yeah, I doubt it's a night and day difference, but it's something worth keeping in mind. My machine also hosts a Pleroma instance, having PostgreSQL DB obviously leads to heavy disk I/O too. In my case storage becomes a bottleneck,ย I might sacrifice 4.0's lower CPU usage for having a more balanced system.