A Dedicated Server
I am now using a dedicated server in my network. For years I used my office desktop to provide pseudo server roles. I also had a full home theater PC (HTPC) housing all of my videos. Then I added a Thinkpad T400 laptop. There were some older networked computers that remained mostly unused.
While that setup worked well, I was uncomfortable with the entire arrangement. I did not like the way my data was scattered across multiple systems. I did not like how none of my data was centralized. I did not like how I needed to keep all three computers powered on all the time.
I built and installed the office desktop in 2007. I installed 32-bit Slackware. I am comfortable with Slackware. Slackware requires sweat equity to use and polish, but is designed to let users tinker. There is little that gets in the way of customizing Slackware and the BDFL and developers try to avoid presuming how anybody wants to use their computer.
For the past year and half I have been using Fedora and CentOS 6 and 7 alongside Slackware. While I enjoy Slackware for its simplicity, being skilled only with Slackware is not easily marketable. Some exposure to Red Hat ways are important in that respect. For more experience, add LMDE, which I was using to install for other people.
As CentOS often is used in servers, as I grew more comfortable with Fedora and CentOS, throughout my year-long planning of my new server I pondered whether I should use CentOS 7. While I might one day move the server to CentOS, I am still using Slackware.
I wanted to focus on one challenge at a time. Remaining with Slackware allowed me to focus on basic issues such as updating shell scripts to the wider purpose of a dedicated server rather than a dual role of desktop and sometimes server. While I had anticipated such adjustments, I was surprised by the little tweaks I needed to many of my scripts.
The process went more or less as I planned and anticipated. I had planned well enough that probably 90% of the migration was complete in two days. As I anticipated, the other 10% took me about three weeks to complete. I continue to shake out a bug or two.
Right now the server is running 32-bit Slackware. My next step is to move to 64-bit. When I partitioned the new hard drives I purposely left an empty partition for Slackware 64-bit. As I never had a need to use Slackware 64-bit I need to learn the nominal differences and again journey through some adjustments with shell scripts.
I migrated my new server from my office desktop. That means I will update the office desktop to 64-bit as well. Then the T400.
For many years I tinkered with some old hardware on my network. That was one reason I remained comfortably with 32-bit Slackware despite my production systems all being 64-bit hardware. Keeping 32-bit installed everywhere helped me much with keeping all systems synchronized. The old systems no longer do anything useful. I needed to let them go. Yes, I have read many articles on how to use old hardware with current distros. The reality is the really old hardware just are not useful anymore. Time to move on and retire those systems.
When I move to 64-bit I will do so concurrently on all systems. With Slackware that means I need to recompile many packages and have that personal repository ready to go before the big push.
When the dust long settles on that effort, I might one day tinker with CentOS 7 on my server.
One reason why I did not immediately consider CentOS 7 is systemd. While I have no dog in the fight with respect to systemd, there are several scripting solutions I use in my systems that I have been unable to move to systemd. I have asked online for help but no sparks occurred. Until, or unless I can resolve those missing pieces, Slackware will remain on my server.
Posted: Category: Usability Tagged: General
Next: Centralizing Work Flow
Previous: Missing Command Line Tweaks