N/B: Parallels have since fixed this in the latest version of Parallels Desktop 15, thus it’s no longer an issue
A little while back I tweeted Parallels via their @ParallelsCares twitter account to find out if they could provide support for Parallels Tools with CentOS 8.
RHEL 8 was released 7th May 2019, with Parallels 15 released 13th August 2019, so since CentOS is a free version of RHEL with the commercial, and copyright protected parts removed, I made the presumption that Parallels 15 would support it. However with CentOS 8 taking until 24th September 2019 to be released, all they did was respond to state that they didn’t support it, with a link to their KB article.
I went about looking for a fix, and it turns out it’s fairly easy. It needs two things:
Pretending to Parallels that what you’re installing is RHEL 8
The EPEL Repo enabled
Here’s the exactly what I did:
Download the CentOS DVD image for the version that you want here
In Parallels, Start the new VM Installation Assistant
Select “Install Windows or another OS from a DVD or image file”
Select “Choose Manually”, then “Select a file…”, and find the DVD image you’ve just downloaded
It will claim “Unable to detect operating system”, click “Continue”
When the Prompt comes up to select your operating system, select “More Linux” > “Red Hat Enterprise Linux”, then proceed through to creating and booting the VM
Proceed with the install
Ensure the network is enabled under “Network & Host Name”
Ensure the drive is checked in “Installation Destination”
To fix the error in “Installation Source”, select “On the network” > “http://”, and enter the following in the text box: mirror.centos.org/centos/8/BaseOS/x86_64/os
Once it’s downloaded the metadata, under the “Software Selection” select the options you want for your install
Proceed with the install, and make sure you enter a root password
Once rebooted under a terminal, install EPEL using the instructions here. Ensure you run the command to enable the PowerTools repository too.
Start the “Install Parallels Tools” process, ensuring that any existing mounted CD/DVD is unmounted. This is needed to mount the Parallels Tools DVD image.
Run the following commands in a terminal: mkdir /media/cdrom mount /dev/cdrom /media/cdrom cd /media/cdrom ./install
Proceed through the install process for Parallels Tools, and you should be done.
If you want to do this on an existing VM, shutdown the VM, go to Settings > General and change the type (above the VM Name), to Red Hat Enterprise Linux, then boot, and perform steps 9-11 above.
I’ve always compiled my software on servers from source. Call me a perfectionist / idiot, whatever, but I do it for several reasons, including making sure I’ve got the latest features and security patches, as well as being able to tailor the software I use on servers so it’s a minimal install of the software, still providing what I require.
Anyways, I’ve just found a quirk with getting MariaDB to starting up. As far as I could tell from the provided systemd .service file, it was being run by the user that owned the data directory I’d configured at compile time, this directory was specified correctly in the my.cnf, and when I tried to run the service manually it worked. but something was blocking it when it came to running it via systemctl.
I was receiving the following messages:
Sep 25 22:37:58 centos7 systemd: Starting MariaDB database server...
Sep 25 22:37:58 centos7 mysqld: 2016-09-25 22:37:58 139993404594304 [Note] /usr/local/bin/mysqld (mysqld 10.1.17-MariaDB) starting as process 7978 ...
Sep 25 22:37:58 centos7 mysqld: 2016-09-25 22:37:58 139993404594304 [Warning] Can't create test file /usr/local/mariadb/data/centos7.lower-test
Sep 25 22:37:58 centos7 mysqld: 2016-09-25 22:37:58 139993404594304 [ERROR] mysqld: File './mysql-bin.index' not found (Errcode: 30 "Read-only file system")
Sep 25 22:37:58 centos7 mysqld: 2016-09-25 22:37:58 139993404594304 [ERROR] Aborting
Sep 25 22:37:58 centos7 systemd: mariadb.service: main process exited, code=exited, status=1/FAILURE
Sep 25 22:37:58 centos7 systemd: Failed to start MariaDB database server.
Sep 25 22:37:58 centos7 systemd: Unit mariadb.service entered failed state.
Sep 25 22:37:58 centos7 systemd: mariadb.service failed.
I was inspecting the provided mariadb.service file, trying to spot anything that might indicate why the user couldn’t write to a folder it owned, when I came across this:
# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full
So there you have it. I’d configured it to have the data directory under the mariadb program directory under /usr. MariaDB was allowing me to configure a data directory at compile time that it knew it wouldn’t be able to boot the daemon and write to (if I used systemd, which, lets face it, is becoming the norm, at-least on RedHat based distros). There’s a lot of guides on the net that as an example have the data directory created under /usr/local/mysql/data. This obviously isn’t an excuse. Using Javascript as an example there’s a lot of bad guides on the internet that produce quick hacks rather than quality long term code.
Recently I changed ISPs. This generally isn’t a big deal. It didn’t cause any difference in speed or connection reliability, however my old ISP had, regardless of me not ordering one, given me a static IP address. I’d taken advantage of this and assigned the IP to a DNS record to give me easy to remember access to my files when I’m away from home. Anyway when I changed ISPs I discovered my new one changed my IP address every few days, which is an unfortunate thing to discover when you’re not at home.
I took a look at my router and found it only supported DynDns, which I then found out that, apart from to some DLink users, didn’t provide provide a free version of their service to the general public, and I don’t have a DLink router.
The next option was a free alternative to DynDns, there were several, and they all required running some kind of linux demon / cron script, which I would then have to alter my existing A record DNS entry to a CNAME to point to the new dynamic DNS record.
Before setting this up I thought I’d look into my existing DNS provider just incase there was any way of updating DNS records on the fly without having to maintain two separate DNS providers. I found that CloudFlare had an API, which I could update records with. The example provided was a Curl example, which made me wonder, surely I could just write a bash script to update the record with via a cron job. I didn’t want to have to install any major scripting language on my minimal Linux distro, excluding any php, perl etc. solution I’d found that worked with CloudFlare.
I checked CloudFlare’s API rate limiting and found it certainly wouldn’t be limiting for what I was trying to do (it’s approximately 1200 requests every 5 mins if you’re wondering). I then found MyExternalIP that could provide my external IP address with a rate limit that was easy to deal with of roughly 1/s, after which it was just a case of writing the bash script.
I worked a script out using Curl requests to get the information I needed including the specific id of the DNS record I was trying to update and then used sed to get the information I needed out each requests response. I made it compatible with the CloudFlareAPI call I was making that way any parameter passed to the call could be passed by a command line argument to the script itself.
The resultant script I added to my crontab to run every half hour. Everything worked perfectly so I thought I’d create a gist at github so others could take advantage of this:
Basically I’ve been looking at upgrading a web-server to the latest version of Fedora 19, or when it’s released later this year CentOS 7.0 (providing it’s easy for them when RHEL 7.0 is released), however knowing that iptables is now becoming redundant in favour of firewalld in Fedora I started looking at updating my web-server install script to work with firewalld. Knowing part of that is Fail2Ban and that uses iptables my first port of call was finding a way of getting these two working together.
My first obvious search for “firewalld fail2ban” returned nothing helpful whatsoever, just people wanting a conf file to get it working with no actually helpful response, however once I found that firewalld uses firewall-cmd on the command line to control the rules I searched for that. This turned up a current bug posted on RedHat’s BugZilla: https://bugzilla.redhat.com/show_bug.cgi?id=979622 , where it turns out a very helpful soul, Edgar Hoch, has created an action.d conf file to get it all working: https://bugzilla.redhat.com/attachment.cgi?id=791126
After upgrading to the latest version of Fedora a few months ago I was terribly un-impressed. The box in question had been upgraded every 6 months (-ish, thanks to Fedora 18) since Fedora 14 and I’d never had any issues, but then came Fedora 19.
To be fair it wasn’t Fedora’s fault per say, it was GNOME 3 and the open source nVidia graphics drivers. The desktop looked ok when you booted the box, but if you tried to use the Activities section, none of the transparency worked, and a lot of the Favourite icons in the dock had a luminous green behind them when you hovered over them. What was worse was trying to launch a non-favourite application, click to do that and you could see the first 6 frequently used ones, but no others, and none under the “all” tab. This obviously made the whole experience pretty much unusable.
I went through the obvious investigations, straight away looking for some better nVidia graphics drivers. I didn’t expect to find any official nvidia drivers after Linus’ hilarious rant last year. However, it turned out there was. I first tried downloading them from nVidia but their installers were less than helpful, and none wanted to install on my system regardless of fulfilling their dependencies. I then tried looking elsewhere and remembered the trusty basic linux guide site If !1 0. I found a guide on there for Fedora 18, and adapted it for Fedora 19, but unfortunately that wouldn’t work due to a mass amount of package conflicts. I’d been meaning to wipe the system for a while and start again, so backed up the /etc/ folder to another drive, wiped the partitions, then installed Fedora 19 and used the guide again and all was fine and dandy. The boot screen is the basic plymouth one rather than the more graphical splash one, but apart from that everything works and I don’t have awful un-usable graphics anymore.
After downloading Fedora 18 and creating a minimal install virtual machine I went straight to doing the default I always do. As I was creating a test server I need to be able to see what’s happening during boot so I disable the graphical boot.
Previously (at-least up to Fedora 15) I’d used the plymouth commands to switch the graphical boot to details which had worked.
[root@localhost ~]# plymouth-set-default-plugin details
[root@localhost ~]# /usr/libexec/plymouth/plymouth-update-initrd
However, when I tried this with Fedora 18, nope, not working, the community to the rescue. Another individual (Nigel Smith) had had the same issue and found the solution in editing the default grub configuration file. So if you need the same visit here:
While I was at it I also noticed that ifconfig produced a “Command not found”. Erm … wha? Where did that go? Isn’t that like a basic linux command? Turns out in Fedora 18 it’s been removed due to the alternative and replacement iproute package being in place for “many years”. So you’ve now got 2 choices:
1. use the ip command:
ip addr
2. install the net-tools package:
yum -y install net-tools
While trying to get MongoDB working on a Fedora 15 test server I found that there was no way of installing the latest version with SystemD control due to a pre-existing known bug.
To Mongo’s credit there is a file provided in the source under rpm/init.d-mongod, however when it comes to this being used by SystemD, well it just errors.
This was frustrating, but as I was doing it on a VM, I did what any logical person would do. Installed Mongo from the package manager, took a copy of the required SystemD files, reverted to a snapshot, then installed the latest version of Mongo from source.
After this I adapted the mongod.service file to use the correct locations, ensured all the required directories, files and users were present on the system then started the service et voila, working latest version of MongoDB on Fedora 15 with SystemD
the two required files are:
/lib/systemd/system/mongod.service
/etc/sysconfig/mongod
Or you can just use the RedHat distro based install script I created:
While creating the new web-server for my employers, to replace a Fedora 10 box which gets no security updates, I needed to compile some software from source, meaning I needed the kernel sources.
Since I couldn’t easily obtain these I needed to install the Kernel provided by the distribution rather than the more recent kernel provided by Linode themselves.