Beta version of Red Hat Enterprise Linux 8.0 was announced recently. It can be downloaded without any registration, or you can go through the Developers Program and get a subscription for development usage for free.
I downloaded the ISO this way and here go a few screenshots from my installation in a KVM environment:
Note: I wrote this post during Christmas break 2017, but it took me some time before I managed to give it a better form, verify the steps again and publish it. Hence some Xmas references in a text published during summer time.
Xmas break is, as usually, just about the right time to either play some really old-school RPG, or to finally get on with some “fun” tasks that you’d been postponing for as much as you could. This year, one such task on my plate was to finally get rid of an old Centos 5 machine with OpenLDAP server where I kept an address book and accounts of my mail server.
For some tasks, it’s never the right time. Like this upgrade of old Centos 5 machine with OpenLDAP 2.3 to Centos 7 and newer version of OpenLDAP, which already stores configuration information in separate files in /etc/openldap/slapd.d, instead of /etc/openldap/slapd.conf as it was the case before. So, despite me postponing this “fun” as much as I could, I finally had to upgrade this old machine of mine.
This is how I went about it. I had a brand new installation of Centos 7 where I installed the server and client packages as the first step:
|
1 |
yum install openldap-servers openldap-clients openldap |
Next, I used slappasswd to generate a hashed copy of some generated password.
|
1 |
slappasswd |
This tool will print the hashed password into standard output. I copy pasted it and used it in this step1.ldif file. Since it’s not recommended to edit OpenLDAP config files directly any more, ldif files are the way to perform config updates now. The below referenced step1.ldif file performs an update of ldap root password.
|
1 2 3 |
vim step1.ldif systemctl start slapd.service ldapadd -Y EXTERNAL -H ldapi:/// -f step1.ldif |
Having added root ldap password, I now created a new database based on a sample config file:
|
1 2 3 |
cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG chown ldap. /var/lib/ldap/DB_CONFIG systemctl restart slapd.service |
and then added schemas that I was interested in:
|
1 2 3 |
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif |
That done, I could proceed to set up the same structure and data as it was the case on my old Centos 5 LDAP server, starting with creating manager role using this step2.ldif file (example.com used as an example domain here):
|
1 2 |
vim step2.ldif ldapmodify -Y EXTERNAL -H ldapi:/// -f step2.ldif |
Now, with manager role added, I could add the structure of People organization using this step3.ldif file:
|
1 2 |
vim step3.ldif ldapadd -x -D cn=Manager,dc=example,dc=com -W -f step3.ldif |
That was it as far as structure was concerned. Now I only had to import the actual data from an ldif dump coming from my old ldap server. The dump of people in database looked a bit like this skeleton file people.ldif (some data like password hashes was removed on purpose, this is just to give you an idea):
When I tried to import it, however, openldap wouldn’t import the data. I had to get rid of some fields that couldn’t be imported as they are generated anew:
|
1 |
cat people.ldif | grep -v "entryCSN\|entryUUID\|structuralObjectClass\|creatorsName\|createTimestamp\|modifiersName\|modifyTimestamp" > people_updated.ldif |
With this new file people_updated.ldif, I was able to import my old data into new directory without any further issues:
|
1 |
ldapadd -x -D cn=Manager,dc=example,dc=com -W -f people_updated.ldif |
Verified by successfully performing a query against that new directory:
|
1 |
ldapsearch -h server_hostname_or_ip -D "cn=Manager,dc=example,dc=com" -W -b "uid=john,ou=People,dc=example,dc=com" |
I home this might come handy to someone who gets stuck on such a “fun” task as I did.
For quite some time, I used to have a low-end motherboard that didn’t support Wake on LAN. So when I left for work or holiday, I would usually leave my home PC on, because sometimes I just needed to access it. Now, with a second-hand, but still significantly newer motherboard I got from my brother, I could finally set up WOL and wake the PC on remotely from a Raspberry that is also running at my place – but Raspberry doesn’t consume so much electricity. As it’s often the case, Debian documentation works for the current stable, while I have buster/testing on my PC at the moment and I had to search for how to to that for a bit. Luckily, I was able to find information elsewhere.
Having enabled the feature in BIOS (it was called “” instead WOL), I had to enable it on the operating system level as well. To make the change permanent, I added this file:
|
1 2 3 |
# cat /etc/systemd/network/50-wired.link [Link] WakeOnLan=magic |
Then, from my rpi, I could just
|
1 |
wakeonlan MAC_ADDRESS |
and it worked.
This is a PC that belongs to my brother in law. He hasn’t been using it for over a year, ever since he switched to Mac, so he’d like to get rid of it. It has i5 (Sandy bridge) inside – not an high-end machine any more, but it can still serve as a decent workstation. I’m considering using it as my second PC, but maybe it will just go to ebay. Either way, it deserved some proper cleaning after years of service, because whatever you do, some places inside which are not easy to reach tend to collect dust over time. So:
So this is my weekend hobby. As good as new.
I installed Centos 7 on a brand new machine about a half a year ago, and set up KVM with two data pools – one just a regular directory for old raw images, the second being an LVM volume group. Later, I added one additional physical disk to the machine, for local backups, which turned out to be an important detail later.
Nowadays I wanted to start a new virtual machine but to my surprise, the data pool based on LVM volume group ‘vg2’ wasn’t active:
|
1 2 3 4 5 |
# virsh pool-list Name State Autostart ------------------------------------------- backups active yes vg2 inactive yes |
The LVM itself seemed to be working just fine, as well as the one virtual machine which was already residing in a logical volume in this particular data pool. But the data pool would not get activated, no matter if I tried from virsh:
|
1 |
unsupported configuration: cannot find any matching source devices for logical volume group 'vg2' |
or from virt-manager:
|
1 2 |
Error starting pool 'vg2': unsupported configuration: cannot find any matching source devices for logical volume group 'vg2' |
Eventually, it turned out that when I had added the physical disk for backups into the machine back then, this new disk got /dev/sda assigned while the original old disk got /dev/sdb as the device name. LVM was able to cope with the change, but libvirt remembered the original value:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# virsh pool-dumpxml vg2 <pool type='logical'> <name>vg2</name> <uuid></uuid> <capacity unit='bytes'>1351803207680</capacity> <allocation unit='bytes'>461373440000</allocation> <available unit='bytes'>890429767680</available> <source> <device path='/dev/sda7'/> <name>vg2</name> <format type='lvm2'/> </source> <target> <path>/dev/vg2</path> </target> </pool> |
Luckily for me, I was not the first one to run into this issue, so it was an easy fix:
|
1 |
<device path='/dev/sdb7'/> |
After changing the device path to the correct device name, data pool was able to start again. In the referenced bug ticket, it was stated that removing the device path altogether works just as well and might actually be a better option because device path is only needed when storage pool is being defined for the first time.
I’ve run across this peculiar problem. I was trying to set up IPv6 on a Centos 6 machine. I thought that it would be a simple task – a couple of minutes at most – as I had done that on other Centos 6 machines before. But I was wrong.
My initial configuration steps were:
|
1 2 |
# cat /etc/sysconfig/network | grep IPV6 NETWORKING_IPV6=yes |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=no BOOTPROTO=none ... IPV6INIT=yes IPV6_AUTOCONF=no IPV6_DEFROUTE=yes NAME="System eth0" IPV6ADDR=2a01:xxxx:xxxx:xxxx::1/64 IPV6_DEFAULTGW=2a01:xxxx:xxxx:yyyy::1 |
Take note of the two (obfuscated) IP addresses, the machine IP address 2a01:xxxx:xxxx:xxxx::1 is in a different subnet than the IP address 2a01:xxxx:xxxx:yyyy::1 of the default gateway given to me by the ISP.
On other machines I had configured in the past, IPV6_DEFAULTGW was 2a01:xxxx:xxxx::1, in other words – my own machine’s IP address 2a01:xxxx:xxxx:xxxx::1 was in a subnet that was a part of the bigger 2a01:xxxx:xxxx:: subnet in which the ISP’s gateway machine was located. In those cases, IPv6 worked without any problems when I used the above mentioned simple configuration. But here, it didn’t work, I was getting the following warning and wasn’t able to connect/ping anywhere:
|
1 |
WARN : [ipv6_add_route] 'No route to host' adding route '::/0' via gateway '2a01:xxxx:xxxx:yyyy::1' |
I tried specifying the interface, like this:
|
1 |
IPV6_DEFAULTGW=2a01:xxxx:xxxx:yyyy::1%eth0 |
but that didn’t help either.
Eventually, I got an advice from a friend who’s far more IPv6 savvy than I am. I had thought that it was not possible to have default gateway in a completely different subnet and that this was the reason why I was running into this problem, but I was told that IPv6, unlike IPv4, did actually allow for a gateway to be in a different subnet, but in those cases, addtional network script has to be configured like this:
|
1 2 3 |
# cat /etc/sysconfig/network-scripts/route6-eth0 2a01:xxxx:xxxx:yyyy::1 dev eth0 default via 2a01:xxxx:xxxx:yyyy::1 |
Having set the gateway this way, I had to remove it from the interface configuration file, of course:
|
1 2 3 4 |
# cat /etc/sysconfig/network-scripts/ifcfg-eth0 ... IPV6ADDR=2a01:xxxx:xxxx:xxxx::1/64 #IPV6_DEFAULTGW=2a01:xxxx:xxxx:yyyy::1 |
After restarting network, this machine was finally IPv6 ready.
I got Raspberry Pi 2 as a present from my brother. It’s a nice toy, I was trying out OpenELEC, it makes for a really nice home theater in combination with a NAS on local network. The only drawback was that the analog sound output produced kind of unpleasant noise. I tried to follow a lot of pieces of advice found around on forums, changed the operating system, drivers, nothing helped. It seemed that the noise was a design problem of the analog sound (the digital sound output was all right).
In the end, I installed Raspbian and started using this Pi as a “thin client” to connect to other computers using X2Go remote sessions. It was a nice use case, but I didn’t need it so often as to actually miss sound. Eventually, I was advised to use an external sound card. A small, $10 USB card did the trick. The noise was gone and now, when using Raspberry as a thin client, I’m able to listen to music on it, too.
Spending a lot of time with mouse and keyboard, I decided I would give it a try with trackball. A friend lent me Logitech Trackman Marble for a week to see if I can get used to it. The one drawback in Linux is that there’s no support for scroll emulation by default. It was relatively easy to set this up on my laptop with help of xinput, but at home, where I’m using Debian 9 (currently ‘testing’ branch) with Mate, this didn’t work. So this had to go to a good old X.Org configuration file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# cat /usr/share/X11/xorg.conf.d/50-trackball.conf Section "InputClass" Identifier "Marble Mouse" MatchProduct "Logitech USB Trackball" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Driver "evdev" Option "ButtonMapping" "1 2 3 4 5 6 7 8 9" Option "EmulateWheel" "true" Option "EmulateWheelButton" "8" Option "ZAxisMapping" "4 5" Option "XAxisMapping" "6 7" Option "Emulate3Buttons" "true" Option "EmulateWheelInertia" "10" EndSection # cat /etc/debian_version 9.0 |
By the way, after two days of using it, I think I’m getting used to it, so I’ll probably buy one for myself.
9 February 2018 update:
As Debian testing keeps rolling on and on, the above mentioned stopped worked for me, and had to be replaced by the following (obviously, there has been a driver change):
|
1 2 3 4 5 6 7 8 9 10 11 |
#cat /etc/debian_version buster/sid # cat /usr/share/X11/xorg.conf.d/50-trackball.conf Section "InputClass" Identifier "Marble Mouse" MatchProduct "Logitech USB Trackball" Driver "libinput" Option "ScrollMethod" "button" Option "ScrollButton" "8" Option "MiddleEmulation" "on" EndSection |
I’ve had this mail server of mine for some time. I was an early adopter of Gmail back then, but as years went on and it became obvious that messages were data-mined by Gmail, I eventually started running my own Postfix server. Not just for me, but for family and eventually other people. Now, the thing is that some folks insist on having their emails forwarded to another service, like Gmail, Yahoo, etc. I can understand that. The problem is that if such mailbox receives a lot of spam messages, those messages get forwarded to Gmail and Yahoo as well, and as a result, my mail server can get bad reputation because of that – I can’t just explain to the other side that those spams are only forwarded.
I’m using Spamassassin to mark spam, but all it can do is to mark the messages for users’ MUAs, it can’t do anything else, like drop or reject unsolicited bulk email so that it doesn’t get forwarded. I’ve used Amavis somewhere in the past and it could have solved the problém here, too, but here it felt as too large a gun for the task. All I wanted was to prevent the most obvious spam with high score points from being forwarded. So I created a file with a regular expression to catch all messages marked as Spamassassin with help of X-Spam-Level header.
|
1 2 |
#cat /etc/postfix/header_checks /^X-Spam-Level: \*\*\*\*\*\*\*.*/ HOLD custom spam rule |
and uncommented this line in:
|
1 2 |
#grep header_checks /etc/postfix/main.cf header_checks = regexp:/etc/postfix/header_checks |
The above mentioned HOLD action will put the messages into the hold queue for further inspection. Other option is to REJECT the messages (more here 
).
To my dismay, it just didn’t work when I gave it a try with help of Gtube. What I didn’t realize was that header_checks happen while message is being received. Spamassassin, however, works as a milter that adds extra headers later, so it couldn’t work. There is a Postfix feature designed to solve this problem – milter_header_checks – which does the same thing, except it takes headers added by milters into account, too. The only tiny drawback was that this feature was added to Postfix 2.7 and my Centos 6 had Postfix 2.6 running. There was a patch on Postfix page which backported milter_header_checks into version 2.6, but I just didn’t have enough courage to go for it. Instead I used the workaround discussed here (many thanks). The trick is to create another service in master.cf and use it as a content filter for the main smtp service. That way, the Spamassassin headers get applied and on the second run, they get noticed by header_checks.
|
1 2 3 4 5 |
#master.cf smtp inet n - n - - smtpd -o content_filter=smtp:127.0.0.1:10025 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= |
I also had to add permit_mynetworks in recipient restrictions, but that was probably relevant just to my particular setup.
|
1 2 |
#main.cf smtpd_recipient_restrictions = permit_mynetworks, |
After the postfix reload, the spam messages with score higher than defined in /etc/postfix/header_checks finally got caught and stopped.
Update 21. 2. 2017:
There was one unintended side effect with the above mentioned solution – all forwarded emails were duplicated and arrived into the final mailbox twice. When there was forwarding set in the aliases file, the rule got applied on both smtpd service, the external one, as well as the internal one, where the header_checks happened. So this behaviour had to be suppressed using receive_override_options=no_address_mappings option to prevent this unintended duplication:
|
1 2 3 4 5 |
smtp inet n - n - - smtpd -o content_filter=smtp:127.0.0.1:10025 -o receive_override_options=no_address_mappings 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= |
I ran into a problem with Apache on Centos 6. For some time, I was the only person who had access to this particular machine so permissions were not a problem. However, now that somebody else is taking care of the website hosted there, they had troubles editing files that were uploaded via website and owned by apache. So I added the user to the apache group and put this line:
|
1 |
umask 002 |
into file:
|
1 |
/etc/sysconfig/httpd |
That way, any file created by apache user was by default writable by the apache group so the given user would be able to work with those files. When I tried it out, however, it didn’t work, the user was not able to modify those files, to my frustration. Now, I was left with two options, either pull my hair off, or modify the httpd init script, neither of them much to my liking. Eventually, I found out that the solution was pretty easy – the PHP upload script was explicitly setting the permissions to 644 so members of apache group were not able to modify the file. When I modified the application and its chmod command, everything worked like a charm.
Update 17. 4. 2017
I came to face the same situation with nginx on Centos 7. The issue was basically the same, only the file where umask directive had to be placed to was different:
|
1 |
/lib/systemd/php-fpm.service |
and umask had to be placed into the [Service] section:
|
1 2 3 |
[Service] #other stuff here UMask=0002 |
My name is Vratislav Hutsky. I work as Associate Manager at Red Hat. Before that, I was a freelance server admin and developer for quite a few years.
