Jan 092015

I finally updated my last machine from openSUSE 12.3 to 13.1 (in the usual way), and with that one I had a bit more fun than the other few times I’ve done this by now.

First mysql refused to start, then quite a few services that were enabled on 12.3 decided to be disabled on 13.1, but nothing during the update “told me so”… but now all seems to work fine.

Dec 022014

I have suggested firewalld from fedora/RHEL7 for inclusion in openSUSE, as an alternative for SuSEfirewall2 for setups with highly volatile networking.

test rpm packages for openSUSE 13.2 can be obtained here:





You will also need to enable the repository from here to get the dependencies.

Nov 232014

I’ve done it again… a live upgrade from openSUSE 13.1 to 13.2.

I’ve been following the usual process that I’ve outlined in a few posts so far, and it went pretty smoothly on three different computers.

The actual process has evolved into this:

  1. run this script (after editing to fix the version numbers):
    mkdir -p ${newrepodir}
    cd ${repodir}
    for repofile in *repo; do
        echo -n converting ${repofile} to ${newrepodir}/$(echo ${repofile}|sed -e "s/${old}/${new}/g") ... ;
        cat "${repofile}" | sed -e "s/${old}/${new}/g" > "${newrepodir}/$(echo ${repofile}|sed -e "s/${old}/${new}/g")" ;
        echo done.
  2. move /etc/zypp/repos.d out of the way, for example rename it to /etc/zypp/repos.d_old
  3. move /etc/zypp/repos.d_13.2 to /etc/zypp/repos.d
  4. clean zyppers cache:
    zypper cc --all
  5. refresh zypper:
    zypper ref

    When you do this, you might get errors for some repositories because they don’t exist yet for 13.2. To disable them, do this:

    zypper mr -d -R 

    On the other hand you might want to investigate if there are 13.2 versions of those repositories, and edit the repo files accordingly.
    Then, repeat the zypper ref command.

  6. Once you can run through zypper ref without errors, get updated versions of zypper, libzypp and rpm, and install them:
    zypper up --download only zypper libzypp rpm
    zypper up zypper libzypp rpm
  7. Once that finished without errors, do the same two commands for the whole distribution (Pay attention to any warnings and/or conflicts here. You’ll have to make the right choices about what should be done to resolve them, and I can’t really give you a recipe):
    zypper dup -l --download only
    zypper dup -l
  8. After all is done you can reboot. The first reboot should lead into textmode in case you have to re-install/upgrade your nvidia or AMD binary drivers. To boot into text mode, append this kernel parameter:

Have a lot of fun!

Jun 252014

Lately I’ve noticed a trend in mobile apps that started on iOS, and even is understandable there due to the sandbox nature of that os.

“Every mobile app will continue to evolve until it contains a web browser, antivirus, and anti theft features, no matter what is initial purpose was.”

In German we call that “eierlegende Wollmilchsau“.
An animal that produces wool, milk, eggs, and meat.
Sure would be nice to have for a farmer, but can’t be done.

So what is the connection to mobiles?

Well, look at this: right now I have on my tablet the different apps that can provide me with anti theft services, but only one of them had that when I installed it.
Same goes for anti virus, two of those, only one had such a feature when I choose to install it.
Or how about memory and storage cleaning… two again, one when I started with them.

Like I said, on iOS this can be understood, since the sand box nature of ios separates apps from each other to a much higher degree than on android…

But android should be different, its Unix after all, where the long standing tradition is to have small tools that do one job really well, and let them talk to each other.

May 312014

In my never ending story for single sign on on KDE4 the last post I had was this one.

There was just one little problem with that method: It stopped working when KDE 4.13 came around…

Now there is a new candidate for solving this, and it works just fine so far.

At this point all I can say is that anyone interested should read this blog post, and that the pam_kwallet package in my OBS project has been updated to the code in that post.

Have a lot of fun!

Dec 282013

Seeing that there are only two more weeks until openSUSE 12.2 reaches end of life, I’m doing my usual upgrade with zypper.

If you are about to say “didn’t you do that already some months ago“, that was a virtual machine…now it’s my “production” system. Let’s hope all goes as well as it did on the VM.

So far all is looking good, but 4500 packages takes some time, so I can’t really say anything yet. I’m doing 12.2 -> 12.3 and KDE 4.11 -> KDE 4.12 at the same time, so it might get a bit hairy at some point.

The fun part comes next week… if this goes well I’ll do the same to my wife’s laptop, where a failure will be way more painful…

Update: finished, all seems to be working fine.

Oct 262013

…at least with KDE4 on openSUSE 12.2.

In a previous post I mentioned that there are single-sign-on methods available for KDE to open the wallet right on login, but they do not work when you’re using NIS accounts.

Turns out they do work after all, you just need make sure that the references to the pam_kwallet module is after pam_unix2.so in common-auth, like this:

# This file is autogenerated by pam-config. All changes
# will be overwritten.
# Authentication-related modules common to all services
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
auth required pam_env.so
auth required pam_unix2.so
auth optional pam_kwalletopener.so use_first_pass
auth optional pam_gnome_keyring.so

After this, you just add the two modules pam_dbus_launch and pam_kwallet in common-session like this (pam_dbus_launch needs to be before pam_systemd, and pam_kwallet at the end):

# This file is autogenerated by pam-config. All changes
# will be overwritten.
# Session-related modules common to all services
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive
session required        pam_limits.so
session required        pam_unix2.so
session optional        pam_umask.so
session optional        pam_dbus_launch.so dbus-launch=/usr/bin/dbus-launch
session optional        pam_systemd.so
session optional        pam_kwalletopener.so    maxwait=60 session_timeout=360 localwallet start_daemon kwalletopener=/usr/bin/kwalletopener
session optional        pam_gnome_keyring.so    auto_start only_if=gdm,gdm-password,lxdm,lightdm

With these settings the pam modules work with any kind of useraccounts. Keep in mind that it will not work for automated logins where the system doesn’t actually prompt for a password.

The required pam modules can be installed from this OBS project.

Sep 212013

As anyone who has attended a RH124 or higher class, or has any experience in Unix/Linux knows, we usually set the system to assume that the local clock runs in UTC. This gives us the advantage that the correction for daylight savings time (DST) gets applied automatically.

The problem with that is that on a dual boot system, Windows automatically assumes that the local clock runs in the local time zone, which messes things up.

The solution is one quick registry hack away:

Start Windows, open regedit, and add a 32bit DWORD in this location:


That’s all there is to it.


Original source (in German) is here.

Apr 152013

Like I already said before, openSUSE 12.3 was released today, and I’ve done the usual live upgrade with zypper.

The upgrade itself worked without any problems, and the resulting installation was usable without issues right from the start.

I logged into KDE 4.10 and everything that I’ve tried works just fine. I admit, I can’t say anything about performance as my test machine is accessed via a NoMachine remote desktop session.

After that I upgraded the KDE 4.10.0 to 4.10.1 from the opensuse build service, and that also went well and posed no problems afterwards. Now I’m waiting for my own repository for 12.3 to rebuild against KDE:Release:410.

I’m pretty confident in saying that with 12.3 the process of a live update via zypper can be done without major fear, as long as one has ones repositories set up properly, and with the right priorities (packman and KDE from OBS should have a higher priority than the stop openSUSE repositories).

Optimization WordPress Plugins & Solutions by W3 EDGE
%d bloggers like this: