$ md5sum -c slackware-15.0-install-dvd.iso.md5
slackware-15.0-install-dvd.iso: OK
And so it begins...
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'
Also: "AllowUsers" is the BEST OpenSSH configuration toggle I can think of.
"PermitRootLogin no" takes care of 70% of SSH attacks
"AllowUsers your_name_here" takes care of the rest.
As long as they haven't guessed your user name of course... 😊
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. 🤦♂️
OSSEC used to have one of the BEST installation procedure: clear, simple, straightforward.
Ladies and Gentlemen, it is with great displeasure that I have to announce this is NOT the case anymore. ☹️
Also: Logwatch - requires "HTML::Entities" apparently.
Running CPAN to install that is opening another can of worms...
Seriously, though, I feel like I am pulling half of CPAN just for that one thing Logwatch script would like to have. What have I done? 🤦♂️
"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... 🤞
Aaaaaaaaand... Complete Rust crash on compiling libclamav ...
Back to the drawing board. ☹️
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!
Also: say what you will about the GNU tools, but at least they made "configure && make && make install" a somewhat predictable process.
LLVM and cmake? Not so much.
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
Solution: download boost 1.78 (the official Slackware 15 version) and see if I can get it compile and install the tools, 'b2' included.
This could take a while... 🤦♂️
Meanwhile a bit of fun: installed 'sl', 'figlet' and 'asciiquarium'.
Now, onto the painful things...
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.
Interesting note on the disk i/o usage. I have tested 4.0.5 and I don't see much of a difference with the previous version... My little machine seems pretty much OK, and that's an Atom machine with 'spinning rust' as you mention.
I will keep an eye on the i/o in the future.
@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.
@ParadeGrotesque
I can neither confirm, not deny it yet, as when I build 3.0 with the same set of libraries and with the same gcc, it results in a segfaulting binary — seems peculiar, but not uncommon as support for 32-bit PowerPC in compilers and tooling is spotty nowadays, lots of bugs!
In any case, this seems worth investigating.