Operating systems - 9

In my Fedora 19 I've been wondering why my NTPd does not start on boot. It used to do so couple of Fedora installations ago. This is not a big deal, so I've been mostly ignoring it. Today I dug up some energy to investigate.

The reason was much simpler than I tought. On my very short checklist were:

1. Confirm that systemd has ntpd.service enabled, it was.
   
2. Confirm that ntpd.service has a dependency to start the service after network interfaces are up, it was chained to do a single ntpdate update and start the daemon after it.
3. Needed interfaces have not been blocked and/or needed interfaces have been enabled in config, everything was out-of-the-box: all network interfaces allowed.
   

The daemon even had the panic-threshold disabled in the config, so it wouldn't choke on startup if time was badly off for some reason. I found no reason for the daemon to start.

However, doing a search for ntpd in /usr/lib/systemd/system revealed what was going on. chronyd.service has Conflicts=ntpd.service in the service description. WTF?! What the hell is chronyd?

According to http://chrony.tuxfamily.org/ it is "a pair of programs which are used to maintain the accuracy of the system clock on a computer". Sounds like a NTPd to me. Running netstat confirmed the fact:

# netstat -nap | fgrep :123
udp        0      0 0.0.0.0:123             0.0.0.0:*                           666/chronyd        
udp6       0      0 :::123                  :::*                                666/chronyd        

The daemon does bind to NTP-ports. To get chronyd running properly, all I had to do was add proper time source and allowed updates from my LAN with allow-directives.

That's it!

My Fedora 19 failed to boot if I had an entry for an iSCSI-mount in /etc/fstab. During boot the system just fell to emergency mode. To get the box to boot, I simply did a "stupd man's solution", and commented the line out. This is what happens if I have the standard line in fstab:

My fstab line is:

/dev/qnap  /mnt/qnap  ext4  defaults  1 0

It took me a while to get back to the issue and investigate, it was that bad. This is the clue I found on Fedora project's documentation about iSCSI. They said, that any iSCSI-volumes should be mounted with a special flag _netdev. I changed to that, and hey presto! During bootup, it first does something and then mounts the iSCSI-drive. I merged those two occurrences into a single photo:

It works! I'm so happy about this. For clarity, the fstab-line is:

/dev/qnap  /mnt/qnap  ext4  _netdev  0 0

During my ventures in the Linux-land, I constantly package and re-package RPMs. Sometimes to introduce new functionality to existing package or to simply get a newer version that distro vendor is prepared to offer. Number of times I've created packaging to software that is not in the distro at all.

Another thing I love using are symlinks. I can have newer and older package of a software and can simply switch with updating the symlink into correct version. When I combined those two, it bit me in the ass.

I had quite simple script-blocks to handle the symlink:

%post
cd /my/package/directory/
%{__rm} -f my.cool.symlink-name
ln -s package/library/my.cool my.cool.symlink-name

%preun
%{__rm} -f /my/package/directory/my.cool.symlink-name

On install, that worked, but on update/freshen there was no symlink left. I was puzzled, why is that? Little bit of googling revealed two pieces of information: RPM spec-file documentation about scripts, especially the Install/Erase-time Scripts -part and 2nd the Fedora Project's packaging information, especially the scriptlet ordering. I'll abbreviate the Fedora's ordering here omitting the non-interesting parts:

1. %pre of new package
   This is the part where my script confirms that the symlink exists.
   
2. (package install)
3. %post of new package
4. %preun of old package
   During update/freshen, this is the part where my script removes the symlink created in 1.)
   Crap!
   
5. (removal of old package)
6. %postun of old package

Further reading of RPM spec-docs said "the argument passed to version 1.0's scripts is 1". Ok, nice to how, but now what? How can I utilize the information? What is the exact syntax for the script? The only usable information I found was in the Fedora packaging instructions, there was an example:

%preun
if [ $1 = 0 ] ; then
  /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

So this was the thing I had to try. My solution is to change the %preun-block:

%preun
if [ $1 -lt 1 ] ; then
  # This is really an un-install, not deleting previous version on update
  %{__rm} -f /my/package/directory/my.cool.symlink-name
fi

I did that and upgraded the package. Poooof! The symlink was gone like there was no change at all. WHY? I upgraded the revision number of the package and upgraded again. NOW it worked! Nice.

There is a simple explanation what happened. It says in the Fedora project's order-list that "%preun of old package". OLD package! It works starting from the next update, but not on the first one.

Anyway I was delighted to get that one sorted.

Previously I've studied the init.d replacement systemd.
Update 4th Jun 2017: See the new version

To my surprise, my contraption from the previous article didn't survive a reboot. WTF?! It turned out that in Fedora 19 the /var/run/ is a symlink into /run/ which has been turned into tmpfs. Goddamnit! It literally means, that it is pointless to create /var/run/<the daemon name here>/ with correct permissions in RPM spec-file. Everything will be wiped clean on next reboot anyway.

So, I just had to study the systemd some more.

This is my version 2 (the Unit and Install -parts are unchanged):

[Service]
Type=forking
PrivateTmp=yes
User=nobody
Group=nobody
# Run ExecStartPre with root-permissions
PermissionsStartOnly=true
ExecStartPre=-/usr/bin/mkdir /var/run/dhis
ExecStartPre=/usr/bin/chown -R nobody:nobody /var/run/dhis/
# Run ExecStart with User=nobody / Group=nobody
ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid
PIDFile=/var/run/dhis/dhid.pid

The solution is two-fold. First an ExecStartPre-directive is required. It allows to run stuff before actually executing the deamon. My first thing to do is create a directory, the minus sign before the command says to ignore any possible errors during creation. The target is mainly to ignore any errors from the fact that creation would fail due to the directory already existing. Anyway, all errors are ignored regardless of the reason.

The second command to run is to make sure that permissions are set correctly for my daemon to create a PID-file into the directory created earlier. That must succeed or there will be no attempt to start the daemon. chowning the directory will fail if the directory does not exist, or any other possible reason.

Sounds nice, huh? Initially I couldn't get that working. It was simply due to reason, that the entire Service-part is run as the user pointed by the User=nobody and Group=nobody -directives. That user was intentionally chosen, because it has very limited permission anywhere or anything. Now it cannot create any new directories into/var/run/. Darn!

This where the solution's 2nd part comes in. Somebody designing the systemd thought about this. Using the PermissionsStartOnly-directive does the security context switch at the last moment before starting the daemon. This effectively changes the default behavior to allow running Service-part as root, except for the daemon. Exactly what I was looking for! Now my daemon starts each and every time. Even during boot.

Another thing which I noticed, is that when I edit a systemd service-file, the changes really don't affect before I do a systemctl --system daemon-reload. It was a big surprise to me, after all in traditional init.d everything was effective immediately.

PS.
Why cronie does not create a PID-file? I had an issue in CentOS where I had not one, but two cron-daemons running at the same time. This is yet another reason to go systemd, it simply works better with ill-behaving deamons like cronie.

I've been using a Windows 8.1 preview for a while and being a web developer, I stumbled into couple of noteworthy issues with IE 11. See my previous entry about Win 8.1.

User-Agent string

There are pretty much 2 variants:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C)

or:

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

The only way I could get the "like Gecko" -mode enabled on a XHTML 1.0 -site, was from developers tools in the Edge-mode. My site also has a <meta http-equiv="X-UA-Compatible" content="IE=9" /> in it, but removing or adding the tag does not seem to have any effect. I'm guessing, that Edge-mode works out-of-the-box only in HTML 5. The important thing to not here is, that IE 11 declares itself as a IE 7.0, but unlike a "real" IE 7, this has Trident rendering engine 7.0. Also there is declaration of a "real-version" or rv:11.0.

Emulating previous browser versions

Gone. The good thing is that F12 developers tools have been completely re-written, but it is impossible to get the classic standards selection. I found two discussions about that. First is from superuser.com and second from stackoverflow.com.

Microsoft's idea is to go to http://www.modern.ie/en-us/virtualization-tools  and use their virtualization service / tools to use a proper old browser. My advice would be: just ignore anybody using the ancient crap. I'd draw the line on IE 9, it still is pretty popular browser, but on my statistics anything older than IE 8 are totally gone.

Getting Zend Framework 1 to detect IE 11 properly

On my projects I have the ZF 1 running. I've been using Browser Capabilies Project's browscap.ini on PHP. It has solid integration into ZF 1. The bad thing is that BCP is not well maintained anymore due to key persons losing interest into maintaining one. Anyway, here is my patch into 5020:

--- php_browscap.ini.orig       2013-07-31 16:20:08.749140271 +0300
+++ php_browscap.ini    2013-07-31 16:24:14.563058655 +0300
@@ -31179,6 +31192,64 @@
 Platform="WinNT"
 Platform_Version=3.1

+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; IE 11.0
+
+[IE 11.0]
+Parent=DefaultProperties
+Comment="IE 11.0"
+Browser="IE"
+Version=11.0
+MajorVer=11
+MinorVer=0
+Beta=true
+Win32=true
+Frames=true
+IFrames=true
+Tables=true
+Cookies=true
+BackgroundSounds=true
+JavaScript=true
+VBScript=true
+JavaApplets=true
+ActiveXControls=true
+CssVersion=3
+
+[Mozilla/*(Windows NT 6.1*64*Trident/7.0; rv:11.0*)]
+Parent=IE 11.0
+Platform="Win7"
+Platform_Version=6.1
+Win32=false
+Win64=true
+
+[Mozilla/*(Windows NT 6.1*Trident/7.0; rv:11.0*)]
+Parent=IE 11.0
+Platform="Win7"
+Platform_Version=6.1
+
+[Mozilla/*(Windows NT 6.2*Trident/7.0; rv:11.0*)]
+Parent=IE 11.0
+Platform="Win8"
+Platform_Version=6.2
+
+[Mozilla/*(Windows NT 6.3*Trident/7.0; rv:11.0*)]
+Parent=IE 11.0
+Platform="Win8.1"
+Platform_Version=6.3
+
+[Mozilla/*(Windows NT 6.3; WOW64*Trident/7.0; rv:11.0*)]
+Parent=IE 11.0
+Platform="Win8.1"
+Platform_Version=6.3
+Win32=false
+Win64=true
+
+[Mozilla/*(Windows NT 6.3; Win64*Trident/7.0; rv:11.0*)]
+Parent=IE 11.0
+Platform="Win8.1"
+Platform_Version=6.3
+Win32=false
+Win64=true
+
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; IE 10.0

 [IE 10.0]

The 2nd glitch is that ZF 1 heavily relies on seeing string "MSIE" in the UserAgent identification to determine, that we're talking about Internet Explorer. IE 11 doesn't state that anymore. It want's to be like Mozilla's Gecko-engine, and happily says so. My patch for ZF 1:

--- library/Zend/Http/UserAgent/AbstractDevice.php.orig 2012-11-16 17:23:41.000000000 +0200
+++ library/Zend/Http/UserAgent/AbstractDevice.php      2013-07-31 13:58:15.422657840 +0300
@@ -512,6 +512,19 @@
         } elseif ($product == 'mozilla' && $result['browser_version'] < 5.0) {
             // handles the real Mozilla (or old Netscape if version < 5.0)
             $result['browser_name'] = 'Netscape';
+        } elseif ($product == 'mozilla' && isset($result['comment']['full']) &&
+            preg_match('#^([^;]+);.+Trident/(.+);\s+rv:(.+)#', $result['comment']['full'], $real)) {
+            // MSIE 10+ in native mode.
+            // In emulation mode, will match MSIE 7.0
+            $result['browser_name'] = "MSIE";
+            $result['browser_engine'] = "MSIE";
+            $result['browser_version'] = $real[3];
+            $result['browser_token'] = 'MSIE ' . $real[3];
+            if (isset($result['others']['full'])) {
+                $result['compatibility_flag'] = $result['others']['full'];
+                unset($result['others']);
+            }
+            $result['device_os_token'] = $real[1];
         }

         /** windows */
@@ -523,6 +536,8 @@
             if (strpos($result['device_os_token'], 'Win') !== false) {

                 $windows = array(
+                    'Windows NT 6.3'          => 'Windows 8.1',
+                    'Windows NT 6.2'          => 'Windows 8',
                     'Windows NT 6.1'          => 'Windows 7',
                     'Windows NT 6.0'          => 'Windows Vista',
                     'Windows NT 5.2'          => 'Windows Server 2003',

That makes ZF 1 react alike for IE 11 and all other versions before that. I did test that on IE 8, IE 9, IE 10 and IE 11. Also I confirmed that to function with IE 10 and IE 11 in IE 7 emulator mode.

64-bit process

Normally I run only 64-bit browsers. Google's crappy Chrome won't do that, so I try to stay away from it. Firefox has excellent spin-off project of CyberFox, most IE versions have 64-bit counterparts, Opera has 64-bit version. The thing with 64-bit browsers is that there are a number of exploits for browsers which are tailored to run on 32-bit processes.

Anyway, the story is that on Windows 8 and Windows 8.1 the tile-mode IE is always 64-bit, but desktop-mode is always 32-bit. Ghacks.net has a story about getting IE 10 in Windows 8 to run 64-bit in desktop-mode, but I fail to confirm the results.

On IE 11 I found a setting of "Enable 64-bit processes for Enhanced Protected Mode":

... I don't know how it should affect the browser behaviour. I'm still getting:

The root-process of IE seems to be 64-bit, but anything with a real web-page in it, is always 32-bit on desktop side. Tile-mode looks like this:

So, no avail for me. Any ideas are welcome.

I was fiddling with a virtual machine and eventually messed it up. My fail made the Linux un-bootable and after a swift assessment I decided to extract the application data and re-install the OS. During my re-install I wanted an expanding virtual disk. As a default Hyper-V Manager creates fixed-size disks, but as my machine is not disk-I/O -dependant, I wanted to consume disk space to make my transfers easier.

Discarding the previous disk and creating a new dynamically expanding one wasn't the hard part. After I attempted to boot my machine for install I got into trouble. The darn thing wouldn't boot! The error text said: "Microsoft Emulated IDE Controller (Instance ID -blah-blarh-blaa-): Failed to Power on with Error 'General access denied error'. IDE/ATAPI Account does not have sufficient privilege to open attachment."

This type of error is widely documented. For example in Microsoft Support Knowledge base Article ID: 2249906. However, they fail to mention how to extract the virtual machine ID. Petri IT Knowledgebase has an article how to get that Get Hyper-V Virtual Machine Process ID and GUID. However, that fails to mention where the virtual machine description files are located at.

After all this research I still didn't have much to go on. Based on the petri.co.il-article, I made a search for files on my computer and deduced the path to be C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines.

Now that I had the virtual machine ID, I made an observation about the file's permissions. In the Microsoft KB-article they instruct you to grant full access -permission for the virtual machine. On my computer the other virtual drives have only read and write access. See this pic:

Full access sounds like an overkill anyway, I think R/W should do the trick in this case. This is what I ended up doing in PowerShell:

C:\Windows\System32\icacls.exe `
 "C:\Users\Public\Documents\Hyper-V\Virtual hard disks\CentOS-V.vhd" `
 /grant "NT VIRTUAL MACHINE\90DBD878-001C-412B-A668-D5BC8311C12E:(R,W)"

Now my machine boots into install.

Well... the short version is: there is nothing new in it. In medium version the new Internet Explorer 11 is an improvement from IE 10, but is still letting me down.

The install-process didn't go without hiccups. Naturally I didn't read any documents and my install halted on serial number requirement. In the Windows 8.1 preview: FAQ Microsoft provides the correct serial, though.

About the IE 11: It seems bit more robust than IE 10 which failed on trivial things if using IE 7 emulation. On IE 11 the developers tools are completely re-written. That's good news to me, who am a web developer. The problem seems to be, that they completely dropped emulation for previous versions. It is pretty much the way to go but ... why did they have to introduce such functionality in the first place?

I get it, browser race is on. It was on hold for 10 years, but in 2008 when Google entered the race with its Chrome, all the other players sure started putting some effort into their product. Which is a good thing. Microsoft's latest response is IE 11 and they simply have to drop the legacy and start shifting gears to catch up with the others. The real problem is that according to my logs, pretty much every IE-version is still in use. With IE 7-10 it was possible to state in HTML, that this site uses IE 7 rendering rules, or alternatively select a rendering mode manually. Now I cannot seem to find such a switch.

About IE 11 speed: It is not that fast. It has some improvements, but still appears sluggish. The IE's Trident (also Opera) layout engine still renders things only after the page is pretty much loaded. This is exactly the opposite way of Chrome, Mozilla and Webkit -engines way of doing things. In IE the page load appears slow to user since there is always a delay when nothing happens. Also IE appears to be bit slow on CSS / DOM -parsing. Most of development effort has gone into JavaScript-speed.

In conclusion: Windows 8.1 upgrade is a major letdown. The new "start" button does not deliver, I'm still using Classic Shell as a start button, IE 11 doesn't deliver. I'm sure I'll update, but it's nothing worth waiting for.

I don't know who stole my €-char. It is supposed to be on AltGr-e, but my keyboard doesn't do it. There is a discussion about the same problem. On the thread on French keyboard layout the problem is not solved.

On my Finnish keyboard layout even Windows On-Screen Keyboard -application displays AltGr-e as the soure, but to my great amazement adds a 2nd source for the €-char, AltGr-5. WTF?! It works! See pic below:

Hope this helps somebody. Unfortunately I could not determine who stole it/where my original euro-key went.

I have couple of own daemons running on my Linux-box. Now that all the distros are going systemd, my scripts are becoming obsolete. Sure, the systemd can piggy-back into old init.d-scripts, but ... I'd rather have them converted to the new way.

Lennart Poettering's blog has a helpful article, which got me started on my project. Also the manual pages for systemd (systemd.service and systemd.exec) proved a very valuable reference.

My daemon is pretty much from the trivial end of daemons. It runs as nobody-user to prevent it from disallowing access to number of places in case something/somebody breaks it. It does the classic fork on start and parent process simply exits. Fortunately systemd programmers anticipated that and there is a perfect support for such startup sequence.

Here is my example. I simply placed a file named dhid.service into directory /usr/lib/systemd/system/. Then I could interface with it by systemctl-command. Example:

# systemctl status dhid.service
dhid.service - DHIS client for keeping track of changing dynamic IP addresses in DNS
   Loaded: loaded (/usr/lib/systemd/system/dhid.service; disabled)
   Active: active (running) since Wed 2013-07-03 15:26:03 EEST; 928ms ago
  Process: 32355 ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid (code=exited, status=0/SUCCESS)
 Main PID: 32356 (dhid)
   CGroup: name=systemd:/system/dhid.service
           └─32356 /usr/sbin/dhid -P /var/run/dhis/dhid.pid

Jul 03 15:26:03 samba dhid[32356]: daemon started

My entire file is here:

[Unit]
Description=DHIS client for keeping track of changing dynamic IP addresses in DNS
After=syslog.target network.target

[Service]
Type=forking
PrivateTmp=yes
User=nobody
Group=nobody
ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid
PIDFile=/var/run/dhis/dhid.pid

[Install]
WantedBy=multi-user.target

It is really that simple! To make the daemon to start on bootup, just use the systemctl enable dhid.service -command.

Most Linux distros have udev. It has been around a while and is pretty much the way of handling physical devices in your box.

In The Old Age™ making a device to be something was very simple. /dev was in regular filesystem and could have permissions/symlinks/whatever set by admins. During modern era creating a symlink or setting permissions is bit more complex. The steps are:

1. Identify the device
2. Figure out the identifying attributes from udev
3. Choose an operation / operations to be executed when the device is found
• This can be during boot or plug'n'play / USB
  
4. Bring it all together in a configuration file readable by udev
   

An example:

External USB-drive/-stick can have pretty much any drive letter assigned into it by SCSI-subsystem during plugin. It can be /dev/sde today and /dev/sdf tomorrow. Trying to figure out the drive letter each time it is plugged in is both tedious and unnecessary. With (simple?) udev-wrangling you can have a /dev/myownusb to access it every time the drive is plugged in. Steps:

1. Identify
1. lsusb is your friend, from the output it is possible to determine that:
   Bus 001 Device 007: ID 1941:8021 My C00l USB-drive
   
2. Today USB-bus 001 device 007 is the drive. What if you plug it into a different USB-port next time? We need to find identifying attribute/attributes to make configuring possible.
1. If we assume that the drive is /dev/sdf this time, all the udev-attributes can be displayed with a:
   udevadm info --query=all --name=/dev/sdf --attribute-walk
   
2. It will reveal a drive serial number in a format similar to:
   ATTRS{serial}=="0000002CE09310500C1B"
3. The operation we'd like to be done when such a USB-device with a matching serial number is plugged into the computer is a symlink.
4. The final step to get this configured would be to create a file into /etc/udev/rules.d/ with a suitable name.
1. I chose my configuration to be /etc/udev/rules.d/99-mylocalrules.
2. The file will contain a single line with identifying information and the operation. Example:
   SUBSYSTEMS=="usb", ATTRS{serial}=="0000002CE09310500C1B", KERNEL=="sd?1", SYMLINK+="myownusb"
   
3. That literally reads: Whenever a new device is introduced into USB-subsystem with suitable serial number and having a partition, the 1st partition will be symlinked into udev with name "myownusb"
   

To get the rule into effect you need to run:

udevadm trigger 

It is not necessary to unplug an already working drive. Just confirm that it worked:

ls -l /dev/myownusb

... or similar. Then just mount:

mount /dev/myownusb /mnt/myownusb

Another example:

I have a weather station connected into my Linux via USB-cable. There is no point of accessing it as a root, but out-of-the-box that's the only way to go. I need to chgrp the device after every boot for regular users to gain access into it.

With above process my identifying factor is the USB ID of the device and operation is to chgrp the device with a suitable group to allow access for those users belonging into the group. The rule is:

SUBSYSTEMS=="usb", ATTR{idVendor}=="1941", ATTR{idProduct}=="8021", GROUP="110"

Yet again the udev-rule reads: Whenever a new device is introduced into USB-subsystem with vendor ID of 0x1941 and product ID of 0x8021 the newly created udev-device will have a group with id 110. I prepared a group with groupadd and confirmed that it exists:

# getent group 110
WH-1080usb:*:110:itsme

After a udevadm trigger the result can be confirmed:

# ls -l /dev/bus/usb/001/007
crw-rw-r--. 1 root WH-1080usb 189, 6 Jun 19 10:07 /dev/bus/usb/001/007

The long(ish) path into the device comes from the lsusb output, it reads:

Bus 001 Device 007: ID 1941:8021 Dream Link WH1080 Weather Station

... and can be also translated as /dev/bus/usb/001/007. Simple, huh?

Fedora Linux guys replaced the ancient Initd with Systemd in Fedora 16. Bold move. I understand it had to be done. It speeds up booting and does a bunch of other things Initd can't or won't.

The classic story when introducing something new is that it has bugs. This particular time I struggled to get my Magic Sysrq key working on boot. Looks like Fedora people failed (at least) two times with it: Bug 760254 in Fedora 16 and Bug 924433 in Fedora 18 describe these shortcomings.

In short, the trouble with this new thing is that your changes won't take effect on boot. Most Linux admins never touch any of the sysctl(8)-settings and continue living successfully. Then there are rest of us, who tinker&tune their boxes to match their requirements. In Fedora Linux there is a directory of /etc/sysctl.d/ into a sysadmin may create a file with own settings to either override existing settings from /usr/lib/sysctl.d/ or set completely new values, which have only their kernel default set.

An example:
To set the Sysrq-key into "dangerous"-mode allowing all possible operations, the value of file /proc/sys/kernel/sysrq needs to be "1". It can be achieved with a file in /etc/sysctl.d/ containing following:

kernel.sysrq = 1

In Fedora the default value according to /usr/lib/sysctl.d/50-default.conf and manual inspection after boot is "16". So, the big trouble is to get the value of "1" stick. After a couple of reboots I realized that it is possible to test the functionality without booting the computer. As a root, simply run:

systemctl restart systemd-sysctl.service

... and watch what happens. The rather complex name of the service is something I couldn't figure out without Fedora discussion forums.

Anyway, after many many failures I concluded that my own settings need to be executed before the file 50-default.conf. To make things easier, systemd-sysctl.service first gathers a full list of files to be processed, then alphabetizes them and finally executes the settings in order. So I made my file to be /etc/sysctl.d/01-myownsettings.conf, which seemed to do the trick! There is a logic behind that, but it is just tricky to figure out.

Linux-distros are having a race for the most popular one. Part of the setup is to have the latest Linux kernel, and any other part of the software library a distro has. This effect yields into a "nice" effect where running the bleeding edge distros (Fedora, ArchLinux, Debian sid, etc.) every now and then something breaks.

The latest race is with PHP programming language which is nearing the 5.5.0 release. It has an RC3 version already out. Now the problem is that distro-guys start using the latest stuff, but PHP has incompatible changes in it. Plenty of things made with PHP 5.4 or 5.3 or ... won't run.

One of them is phpLDAPadmin. For some incomprehensible reason they are using stuff, which has been flagged as obsoleted years ago. So, it won't work. Luckily somebody at Debian made a fix. That makes my system's LDAP-admin working again. Hopefully somebody does the same with with all of the PEAR packages.

This is what you get when running alpha version of Fedora 19.

Windows 7 and 8 IPv6-stack has a nice feature. Every now and then when waking up from sleep/hibernate there is no autoconfigured IPv6-address. It looks like this when checking for IPv6-address with netsh interface ipv6 show address:

Interface 12: WiFi

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Other      Preferred     infinite   infinite fe80::227:10ff:1234:5678%12

Note how there is only link-local address and no "proper" IPv6-address. On Windows 7 there is a fix. Just disable the Teredo-interface:

netsh interface teredo set state disabled

After that IPv6-autoconfiguration works much better. That doesn't do the trick for Windows 8, tough. I have no idea what would help. My only fix is to discard autoconfiguration and manually set an IPv6-address. This setting won't survive a reboot, so it will keep using autoconfig under normal conditions. But anyway, this is what I do to fix my laptop:

netsh interface ipv6 add address "WiFi" 2001:1234:5678:0:227:10ff:1234:5678

After this, netsh interface ipv6 show address will function properly:

Interface 12: WiFi

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Manual     Preferred     infinite   infinite 2001:1234:5678:0:227:10ff:1234:5678
Other      Preferred     infinite   infinite fe80::227:10ff:1234:5678%12

If anybody knows how to fix this, please drop me a comment.

This is a cool move! At least Arch Linux and Fedora Linux have done this. A typical root directory listing will look like this:

lrwxrwxrwx.   1 root root     7 May 30 23:17 bin -> usr/bin
lrwxrwxrwx.   1 root root     7 May 30 23:17 lib -> usr/lib
lrwxrwxrwx.   1 root root     9 May 30 23:17 lib64 -> usr/lib64
lrwxrwxrwx.   1 root root     8 May 30 23:17 sbin -> usr/sbin

The /bin, /lib and /sbin have been in the root directory since first Unix was released in 1969. Any modern Linux distro won't have and won't need that many partitions than the legacy *nixes used to have. The reasoning is in this discussion thread.

Arch Linux guys have a pretty complex update process. The classic pacman -Syu won't do it for you this time.

On my previous post about Samba 4, I stumbled on printers.

I had a weird warning in my log:

../source3/param/loadparm.c:3121(lp_do_parameter)
  Ignoring unknown parameter "printer admin"
        printer admin = root

The fix to do is drop:

printer admin = root

from smb.conf. Instead it needs to be done run-time, like this:

smbpasswd -a root
net rpc rights grant root SePrintOperatorPrivilege

First a password is required for root-user. I have one in LDAP, but for some reason a local password is required too. After that permissions for printer administration are granted separately. That pretty much concentrates privilege handling out of any text-files.

The other issue was printer sharing to Windows. It had an easy fix. I deleted the existing printer from Windows and added it again. CUPS had renamed the printer and it was not available with the same name. A basic CUPS / Samba setup with cupsaddsmb does the trick.