Menu Close

Category: LoneStar Network

Farewell to 32-bits

views

My mail server was installed in 2007 and has always been a 32-bit system. It was originally a physical machine, a Pentium-based assembled unit. In 2010 I virtualized it with a p2v (physical to virtual) operation performed via rsync.

Since then it has always run inside a 32-bit virtual machine in VMWare. No particular problem as Slackware Linux still continues to actively support the 32-bit distribution, keeping it completely in sync with the 64-bit version.

Recently, however, I faced the problem of deciding whether it made sense to continue keeping this one 32-bit server while all my others are 64-bit. Especially because, for specific reasons, I started compiling the kernel independently for all my virtual machines, which forced me to set up a compilation VM for 64 bits and one for 32 bits, and therefore to repeat the compilation of the kernel twice.

Furthermore, the fact that Slackware Linux continues to support the 32-bit distribution does not mean that it will continue to do so forever. Virtually all major distributions in recent years have made the decision to only offer a 64-bit version that has enough compatibility to run 32-bit binaries as well. It is possible that sooner or later Slackware Linux will also make this type of decision.

So I convinced myself to switch the server to 64 bit. However, I didn’t want to do a clean installation and then migrate the services. There are 17 years of configurations and customizations in this server and having to do it all over again is one of the reasons why I have never thought about converting it until now. I also like the idea of preserving the age of installation of a server, a bit like when you try to preserve uptime for as many days, months, years as possible.

I therefore thought of using a conversion method that was not officially supported but which logically had every chance of working, that is, taking the latest 64-bit Slackware Linux installation DVD corresponding to the update level of my 32-bit server , boot the virtual machine with this DVD and mount the installed OS partition, then replace all the installed packages with the equivalent 64-bit packages. Finally, reset the kernel to boot and go.

I tested this operation on a clone of the vm and it worked without problems. So after some time I acted on the actual machine with positive result.

After booting and starting the system, now 64 bit, I proceeded to recompile and reinstall the binaries coming from packages that were not part of the official DVD.

The whole thing took about 4-5 hours in total but it was worth it. Now the mail server is to all intents and purposes a 64-bit system originally installed in 2007 but to all intents and purposes upgradeable and maintainable like all the other 64-bit systems in my possession.

Removal of Facebook Login

views

Starting today the option to use the Facebook login to authenticate on this blog has been removed.

From what I have learned, during 2023 Facebook changed its terms of service making the business verification of developer accounts a requirement for being given access to the data necessary to use the Login function. Initially it was however possible to register as a Business simply by providing your identity card.

After a few months they changed their terms again and it became necessary to provide proof of a real business activity (registration with the chamber of commerce, etc.).

Consequently, it is no longer possible to use the Facebook Login for purely amateur purposes by individual users. I’m sorry, but it’s not my fault.

For now, logins via Google and Twitter remain active.

Reverse proxy and SSO

views

Nginx logoIn recent times I have made some technological changes to the LoneStar Network services, which are not directly visible but which have improved and made them safer. In particular, I proceeded to place all websites behind nginx reverse proxy. In this way, therefore, the various web servers that present the services are not directly exposed to the network but are located behind the barrier constituted by the reverse proxy.

This also added some flexibility in being able to add subservices presented as subfolders of the main sites.

I have also added a Single Sign On service, to allow access with a centralized account. Not all the services I use support it yet, but over time it should become the only login system.

Restyling the website

views

As you can notice I’m working on the restyling of the website, a thing that I should have done many years ago.

The wordpress theme Revolution Code Blue that I’ve been using until now hasn’t been updated anymore since the early 2000s. It has been working nicely until the release of WordPress 5.1, but with the symultaneous upgrade to PHP 7.3 and WordPress 5.3 some issues have begun to appear in the visualization of some items in the pages.

After some research I’ve reached to the Customify theme, which allows me to build various parts of the site in the way I want instead of giving a mandatory structure. In addition, it matches well with my logo, which I had no intention to change.

The restyling of the website is not finished in full yet, but I should soon achieve the final look.

New SSL certificates by Let’s Encrypt

views

httpsBetween yesterday and today I changed the SSL certificate used on the websites of lonestar.it and unixportal.net, and for the SMTP / IMAP mail services of mail.lonestar.it.

Up to now I used a wildcard certificate, regularly purchased on StartSSL . It was a cost-effective service to get a 2-year wildcard certificate. The convenience is that the certificate was valid for * .lonestar.it, and therefore in any network service.

But the StartSSL Certification Authority has been deprecated by major browsers because of some irregularities committed after acquisition by a Chinese company.

As a result, as of recent versions of Firefox and Chrome, certificates issued by this authority are no longer accepted as valid (green color next to the url bar), but are shown as unrecognized (red color next to the url bar).

So I’ve decided to start using the free service of Let’s Encrypt , which has been very successful lately thanks to the new philosophy of free release of certificates to anyone, for a short time (90 days maximum), so as to encourage adoption of https and tls protocols by everyone.

The short duration of certificates implies the transition to an automatic renewal and replacement mechanism, compared to the previous habit of obtaining a valid certificate for a few years and then install it manually on the various servers involved.

Let’s Encrypt offers an official python-based client to perform these automated tasks on the most popular distributions and common services. But since I use Slackware as distribution and s/qmail as a mail service, I preferred to use the Dehydrated script, which is based on bash and curl.

So I’ve set up some scripts that request certificates, no longer wildcard but individual for each service, and install them where necessary.

All seems to be working 🙂

CC BY-NC-SA 4.0 .