Well, that didn’t go well. I skipped reading the ReadMe on upgrading to Fedora 36 on Moodle.org and after upgrading I realized I was on PHP 8.1 and Moodle doesn’t run on that version. I followed these instructions https://computingforgeeks.com/how-to-install-php-on-fedora/ to install the REMI repository and then PHP 8.0. I did get into some particulars with ensuring that the zip library was installed as different versions report back different entities. In the end it all sorted out and while I don’t have a lovable generic Fedora install I at least have Moodle 4.0 back up and running in time for the school year.
Where did the day go? Down the rabbit hole of SysAdmin work and so, while not particularly wasted, wasn’t time well spent.
It started when I decided to upgrade my server to Fedora 30, surprisingly enough, that went smoothly, took a coffee break and a lunch hour and everything came up smelling like a rose. I was due after last summer on the cosmic break board.
While that was going on was going on I decided to post a blog entry and that was when I went down the rabbit hole. First I updated all the blogs and then turned to the article and started by heading off to download an infographic from a link I was emailed, but as it was a tracker, it was blocked by my Pi-hole. I attempted to temporarily disable the pihole and found I could not login via the web interface. Using SSH, I was able to determine I had run out of storage space…but why?
I tracked it back to using the version of software, NOOBS that came with it. Lazy and as a result the 8GB card had only 5GB of storage and it was full with the base install. I certainly could have simply deleted a few of the apps (Mathematica and Wolfram Alpha being the largest unused apps I generally pull off) but as it is a rainy day, I optimistically put off gardening to between showers, little sensing how long this was going to take to put a clean copy of Raspbian on it.
It went very slowly, I forgot why I like to pull of those apps, and that old memory card is left to a slow older standalong Pi duties like Pi-hole, the update took forever but eventually I was rewarded with a reloaded from scratch Pi-Hole with plenty of space.
Now I was ready to make a blog entry and be quick about it as the update to Fedora 30, which takes at least a coffee break and full lunch to complete was already done. Except the Pi I used for the Pi-Hole to update wasn’t starting the HDMI. Aha I thought, the old HDMI recognition issue I thought, and sure enough the /boot/config.txt file was mangled slightly with a comment that NOOBS had made changes, argh, I might as well reload this one as the rain continued and so I did. It turned out that my new Pi case with a fan and everything has simply been reluctant to let the HDMI cable go all the way in and by the time I solved that I had updates going everywhere.
So after all of that, I don’t have time to post the entry to the blog, didn’t get any gardening done, didn’t get to read a little, and I am back to where I was at the start of the day although up to date in a maintainable fashion.
I suppose it is worth it; however, I have found that my view has completely changed. I no longer think it reasonable to spend time on System Administration, life is too short.
Fedora 24 is official. I decided to jump in on my production server as I had just risked everything taking care of the Ants. Seriously, my Cisco, Server, and Printer/Scanner were infested in their temporary location. They have never been so clean.
I was going to go straight to FedUp like I had in the past; however, according to the documentation page:
FedUp (FEDora UPgrader) was the official tool for upgrading between Fedora releases, until the introduction of the DNF system upgrade plugin. FedUp is now obsolete and should not be used in any circumstances.
And I imagine I had been using it one or two updates too many, being slow to convert to DNF. Installing the DNF upgrade plugin, which appears to be default is the recommended and supported way to upgrade from Fedora 23 to Fedora 24.
I have also seen that you should be able to update to Fedora 24 Workstation using the Software app, although I haven’t tested it and my system is “headless”.
Assuming you have backed up your system , perhaps using deja-dup. Update your machine and install the DNF plugin
$ sudo dnf upgrade --refresh
$ sudo dnf install dnf-plugin-system-upgrade
Part 1 – download upgrades to prepare for the upgrade
$ sudo dnf system-upgrade download --releasever=24
This command will begin downloading all of the upgrades for your machine locally to prepare for the upgrade. You may wish
If you have issues when upgrading because of packages without updates, broken dependencies, or retired packages, add the
--allowerasingflag when typing the above command. This will allow DNF to remove packages that may be blocking your system upgrade.
Part 2 – Reboot and upgrade
$ sudo dnf system-upgrade reboot
Your system will restart after this. In past releases, the
feduptool would create a new option on the kernel selection / boot screen. With the new
dnf-plugin-system-upgradepackage, your system reboots into the current kernel installed for Fedora 23; this is normal. Shortly after the kernel selection screen, your system begins the upgrade process.
Now might be a good time for a coffee break! Once it finishes, your system will restart and you’ll be able to log in to your newly upgraded Fedora 24 Workstation.
I flew through without any issues, but if there are issues, check out the DNF system upgrade wiki page as well as Fedora Magazine’s Upgrading Fedora 23 to Fedora 24 article. I followed their directions for the most part and have put the salient ones in here so I can remember as I upgrade all my workstations.
When I set up my Moodle Server, one of the things that I wanted to do was be able to send the emails to the students as well as logs and various system emails.
Creating your Relay
If you haven’t done so already, you need to install postfix first.
# dnf install postfix
Next you need to open the /etc/postfix/main.cf file in your favorite editor
# i /etc/postfix/main.cf
At the bottom, add the following lines:
# sets gmail as relay relayhost = [smtp.gmail.com]:587 # use tls smtp_use_tls=yes # use sasl when authenticating to foreign SMTP servers smtp_sasl_auth_enable = yes # path to password map file smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd # list of CAs to trust when verifying server certificate smtp_tls_CAfile = /etc/ssl/certs/ca-ca-bundle.crt # eliminates default security options which are incompatible with gmail smtp_sasl_security_options =
# To correct gmail rejecting your email with something similar to “530 5.7.0 Must issue a STARTTLS command first.”
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
And you will need to create a tls_policy file in /etc/postfix that has the following line
Then run postmap /etc/postfix/tls_policy to create the hash of the file.
Next you’ll have to edit (or create) the sasl_passwd file that’s used in the postfix configuration above
# vi /etc/postfix/sasl_passwd
The format of this file is this:
After creating this file, you need to run the postmap command to create the hash of the password file and then make sure that postfix owns the files (as they are created by root originally).
chown postfix /etc/postfix/sasl_passwd*
chown postfit /etc/postfix/tls-policy*
Finally restart postfix using this command:
systemctl restart postfix.service
Testing your configurations
If everything worked correctly, you should be able to test your mail setup by sending an email from the command line. There are multiple methods for this, but I’ll show you two of them here.
The first method uses the mail command. (you should be able to do this as either root or a regular user) firstname.lastname@example.org should be replaced with your intended recipient’s email address.
mail -s “Subject: Test email from linux server” email@example.com
The editor will open up, so you can type a message in the body. You’ll use CTRL+D or enter a “.” to exit this editor.
Next, if you want to CC anyone, you can add their email addresses, and/or press CTRL+D to exit this portion.
The email should send. Check your inbox (and spam folders) to see if it’s arrived. If not, you can check /var/log/maillog (or in /var/log/mail) to find out what’s wrong.
My thanks to a number of sites, each of which provided me some of the information to get this done. I merely cleaned it up to and pasted it together to work on Moodle with this version of Fedora.
The Raspberry Pi Fedora Remix provides a complete software environment for the Raspberry Pi, a $35 computer system designed to spur interest in computer science, software development, and electronic technology among young people. This software release marks an important milestone in Seneca’s Centre for Development of Open Technology’s (CDOT) applied research in building open source software for emerging low-energy ARM systems. Seneca students and faculty have collaborated with the Raspberry Pi Foundation – http://www.raspberrypi.org – and the Fedora Project to prepare open source software to run on this device. More information on CDOT: http://cdot.senecac.on.ca