Google ads

 

It seems that “the community” consists of three separate groups of people:

  1. the people who loudly demand features
  2. the developers who loudly debate the ethic, moral, technical religious impacts if the features demanded by 1.) would be implemented
  3. the small group of developers who watch 1. and 2. and at some point say “Oh for crying out loud. What a noise over 5 lines of code.”

As an example, look at the discussion over the feature request in kmail where someone wants kmail to be able to remove attachments from mails.

As another example, look at this one… Some people would like to see single-sign-on in KDE4. The discussion was long and loud.

And… if you google a bit… you find that the wallet daemon has had the required dbus call since KDE 4.4.2, for crying out loud!

Just that noone has bothered to point a finger at the required pam modules and helpers.

I’ve packaged them for openSUSE, get them from my OBS project and configure them as described in the readme files included in the packages… and you have single sign on.

Note: single sign on only happens if you actually enter a password on login. The typical suse setup with an user session starting automatically on boot can’t work with this.

Note: this seems to work only for local useraccounts, but not in a NIS environment.

 

I’ve been testing openSUSE 12.1 RC2 for a week now, and so far I’m impressed.

Network installation went pretty well (after I had figured out that the reason for the initial woes was the DHCP server here at work, not suse…), and so far a lot of stuff that used to need manual intervention “just works” now, for example the use of ksshaskpass for ssh-add and other little quirkies.

On the other hand there are a few oddities, none of them being the fault of the openSUSE people, as far as I can tell:

  • kopete refuses to “do” MSN – MicroSoft has changed something on their end; kmess needed a patch & rebuild as well
  • no sun java – oracle has changed the licensing and disallows redistibution now.

Other than that: cool beans.

Especially KDE4 is impressive on this version… KDE 4.7.2 actually works now.

 

Some of you might have heard of tmpfs.
For those who haven’t, here’s a link to wikipedia. In short, tmpfs is what amounts to be the good old trusted ram disk. How can this be useful to speed up your computer?

Simple enough, use it for temporary files. On unix systems, that usually means putting /tmp on a tmpfs. On openSUSE, all you need to do is putting this line in your /etc/fstab (after cleaning out /tmp or the mount won’t work):

none                 /tmp                 tmpfs      size=1024m,defaults                   0 0

That line creates a ramdisk of 1Gbyte under /tmp.

but… what if you restart your computer? Right, everything in /tmp will be gone. So, if you don’t want to lose your stuff in there, you’ll need this little script:

#!/bin/sh
#
#     Template SUSE system startup script for example service/daemon FOO
#     Copyright (C) 1995--2005  Kurt Garloff, SUSE / Novell Inc.
#         
#     This library is free software; you can redistribute it and/or modify it
#     under the terms of the GNU Lesser General Public License as published by
#     the Free Software Foundation; either version 2.1 of the License, or (at
#     your option) any later version.
#                            
#     This library is distributed in the hope that it will be useful, but
#     WITHOUT ANY WARRANTY; without even the implied warranty of
#     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#     Lesser General Public License for more details.
#     
#     You should have received a copy of the GNU Lesser General Public
#     License along with this library; if not, write to the Free Software
#     Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307,
#     USA.
#
# /etc/init.d/synctmpfs
#   and its symbolic link
# /(usr/)sbin/rcsynctmpfs
#
# Template system startup script for some example service/daemon synctmpfs
#
# LSB compatible service control script; see http://www.linuxbase.org/spec/                                                                                              
#                                                                                                                                                                        
# Note: This template uses functions rc_XXX defined in /etc/rc.status on                                                                                                 
# UnitedLinux/SUSE/Novell based Linux distributions. If you want to base your
# script on this template and ensure that it works on non UL based LSB
# compliant Linux distributions, you either have to provide the rc.status
# functions from UL or change the script to work without them.
# See skeleton.compat for a template that works with other distros as well.
#
### BEGIN INIT INFO
# Provides:          synctmpfs
# Required-Start:    boot.localfs
# Should-Start:     
# Required-Stop:     boot.localfs
# Should-Stop:      
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: synctmpfs XYZ daemon providing ZYX
# Description:       Start synctmpfs to allow XY and provide YZ
#       continued on second line by '#<TAB>'
#       should contain enough info for the runlevel editor
#       to give admin some idea what this service does and
#       what it's needed for ...
#       (The Short-Description should already be a good hint.)
### END INIT INFO
#
# Any extensions to the keywords given above should be preceeded by
# X-VendorTag- (X-UnitedLinux- X-SuSE- for us) according to LSB.
#
# Notes on Required-Start/Should-Start:
# * There are two different issues that are solved by Required-Start
#    and Should-Start
# (a) Hard dependencies: This is used by the runlevel editor to determine
#     which services absolutely need to be started to make the start of
#     this service make sense. Example: nfsserver should have
#     Required-Start: $portmap
#     Also, required services are started before the dependent ones.
#     The runlevel editor will warn about such missing hard dependencies
#     and suggest enabling. During system startup, you may expect an error,
#     if the dependency is not fulfilled.
# (b) Specifying the init script ordering, not real (hard) dependencies.
#     This is needed by insserv to determine which service should be
#     started first (and at a later stage what services can be started
#     in parallel). The tag Should-Start: is used for this.
#     It tells, that if a service is available, it should be started
#     before. If not, never mind.
# * When specifying hard dependencies or ordering requirements, you can
#   use names of services (contents of their Provides: section)
#   or pseudo names starting with a $. The following ones are available
#   according to LSB (1.1):
#       $local_fs               all local file systems are mounted
#                               (most services should need this!)
#       $remote_fs              all remote file systems are mounted
#                               (note that /usr may be remote, so
#                                many services should Require this!)
#       $syslog                 system logging facility up
#       $network                low level networking (eth card, ...)
#       $named                  hostname resolution available
#       $netdaemons             all network daemons are running
#   The $netdaemons pseudo service has been removed in LSB 1.2.
#   For now, we still offer it for backward compatibility.
#   These are new (LSB 1.2):
#       $time                   the system time has been set correctly
#       $portmap                SunRPC portmapping service available
#   UnitedLinux extensions:
#       $ALL                    indicates that a script should be inserted
#                               at the end
# * The services specified in the stop tags
#   (Required-Stop/Should-Stop)
#   specify which services need to be still running when this service
#   is shut down. Often the entries there are just copies or a subset
#   from the respective start tag.
# * Should-Start/Stop are now part of LSB as of 2.0,
#   formerly SUSE/Unitedlinux used X-UnitedLinux-Should-Start/-Stop.
#   insserv does support both variants.
# * X-UnitedLinux-Default-Enabled: yes/no is used at installation time
#   (%fillup_and_insserv macro in %post of many RPMs) to specify whether
#   a startup script should default to be enabled after installation.
#   It's not used by insserv.
#
# Note on runlevels:
# 0 - halt/poweroff                     6 - reboot
# 1 - single user                       2 - multiuser without network exported
# 3 - multiuser w/ network (text mode)  5 - multiuser w/ network and X11 (xdm)
#
# Note on script names:
# http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/scrptnames.html
# A registry has been set up to manage the init script namespace.
# http://www.lanana.org/
# Please use the names already registered or register one or use a
# vendor prefix.

# Check for missing binaries (stale symlinks should not happen)
# Note: Special treatment of stop for LSB conformance
synctmpfs_BIN=/usr/bin/rsync

test -x $synctmpfs_BIN || { echo "$synctmpfs_BIN not installed";
 if [ "$1" = "stop" ]; then exit 0;
 else exit 5; fi; }

# Source LSB init functions
# providing start_daemon, killproc, pidofproc,
# log_success_msg, log_failure_msg and log_warning_msg.
# This is currently not used by UnitedLinux based distributions and
# not needed for init scripts for UnitedLinux only. If it is used,
# the functions from rc.status should not be sourced or used.
#. /lib/lsb/init-functions

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     be verbose in local rc status and clear it afterwards
#      rc_status -v -r  ditto and clear both the local and overall rc status
#      rc_status -s     display "skipped" and exit with status 3
#      rc_status -u     display "unused" and exit with status 3
#      rc_failed        set local and overall rc status to failed
#      rc_failed <num>  set local and overall rc status to <num>
#      rc_reset         clear both the local and overall rc status
#      rc_exit          exit appropriate to overall rc status
#      rc_active        checks whether a service is activated by symlinks
. /etc/rc.status

# Reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0       - success
# 1       - generic or unspecified error
# 2       - invalid or excess argument(s)
# 3       - unimplemented feature (e.g. "reload")
# 4       - user had insufficient privileges
# 5       - program is not installed
# 6       - program is not configured
# 7       - program is not running
# 8--199  - reserved (8--99 LSB, 100--149 distrib, 150--199 appl)
#
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signaling is not supported) are
# considered a success.

case "$1" in
 start)
 echo -n "Syncing to tmpfs "
 ## Start daemon with startproc(8). If this fails
 ## the return value is set appropriately by startproc.
 rsync -aAX /tmp-bak/ /tmp/
 # Remember status and be verbose
 rc_status -v
 ;;
 stop)
 echo -n "backing up tmpfs "
 ## Stop daemon with killproc(8) and if this fails
 ## killproc sets the return value according to LSB.
 mkdir -p /tmp-bak
 rsync -aAX /tmp/ /tmp-bak/

 # Remember status and be verbose
 rc_status -v
 ;;
 *)
 echo "Usage: $0 {start|stop}"
 exit 1
 ;;
esac
rc_exit

 

activate it with this command:

chkconfig synctmpfs on

On boot this will copy /tmp-bak into /tmp after the filesystems have been mounted, and on shutdown it will copy /tmp into /tmp-bak.

Now you’ll notice a distinct increase in speed at starting KDE, for example. Another application would be your browser cache.

 

 

Here’s a little followup to my previous post about how to upgrade to 11.4.

This one describes how to make the whole process even more risky. You have been warned.
It’s even possible to do this remotely through a ssh session. If you attempt to do that, do it from inside a screen session!

Actually, this first bit makes it a bit easier:

#!/bin/bash

repodir=/etc/zypp/repos.d
newrepodir=/etc/zypp/repos.d_11.4
old=11.3
new=11.4

mkdir -p ${newrepodir}

cd ${repodir}

for repofile in *repo; do
{
 echo -n converting ${repofile} to ${newrepodir}/$(echo ${repofile}|sed -e 's/11.3/11.4/g') ... ;
 cat "${repofile}" | sed -e 's/11.3/11.4/g' > "${newrepodir}/$(echo ${repofile}|sed -e 's/11.3/11.4/g')" ;
 echo done.
}

done;

This script creates a directory /etc/zypp/repos.d_11.4 with all your configured repos switched to their 11.4 counterparts.

After you run this script, all you have to do is move the old /etc/zypp/repos.d out of the way, rename the new one to /etc/zypp/repos.d and make sure that all the paths in the repo files exist. If they don’t, “zypp ref” is going to complain.

now, before you begin, run these two commands:

zypper cc --all
zypper ref

The first one clears all zypper cache folders, the second one refreshes all repositories (here’s where you’ll see if all paths are correct).
If you have a custom X11 setup (dualscreen or such), now would be the point to make a copy of your xorg.conf file.
Now you jump into the instructions in my previous post, right at #6.

 

Here’s a quick and dirty HOWTO about upgrading from openSUSE 11.3 to 11.4, with all additional repos enabled…

  1. Switch to runlevel 3: as root, execute “init 3″
  2. Login as root
  3. Make a backup of all your repositories:
    cd /etc/zypp
    cp -r repos.d repos.d_11.3
  4. Go through all your .repo files in /etc/zypp/repos.d and replace “11.3″ with “11.4″.
    Here’s a “before/after” example:
    before: 

    [openSUSE 11.3 OSS]
    name=Haupt-Repository (OSS)
    enabled=1
    autorefresh=0
    baseurl=http://download.opensuse.org/distribution/11.3/repo/oss/
    path=/
    type=yast2
    keeppackages=0

    after:

    [openSUSE 11.4 OSS]
    name=Haupt-Repository (OSS)
    enabled=1
    autorefresh=0
    baseurl=http://download.opensuse.org/distribution/11.4/repo/oss/
    path=/
    type=yast2
    keeppackages=0
  5. Refresh your repository cache:
    zypper ref
  6. Upgrade zypper:
    zypper install zypper

    You have to pay attention on the list of conflicts. Generally the best of the proposed solutions is the one the would uninstall the least number of packages while still installing/upgrading what you want.

  7. Do the full upgrade:
    zypper dup

    Again, pay attention to any listed conflicts, and resolve them carefully. Again, the best of the proposed solution would be the one that installs what you want while uninstalling as little as possible.

  8. The scary moment:
    Reboot your system. If all went well you will be greeted by a working openSUSE 11.4 installation.
  9. Cleaning up afterwards:
    Login as root, and run the following command:

    LANG=CTYPE zypper search -si | grep "(System Packages)"| cut -d "|" -f 2

    That will list all installed packages that are not available from any of the configured repositories anymore.
    You might want to carefully remove them one by one with “zypper remove”. If you use “zypper remove -u” instead, you will also remove all dependencies that are not needed anymore. This can really break things.

 

I just installed 11.4 M6 in a VirtualBox VM, and all I can say is that I’m going to upgrade all computers that I can lay my hands on to 11.4 as soon as possible.

For one simple reason.

SCPM is back (at least in M6).

That being said, KDE 4.6 doesn’t look half bad either.

 

Yesterday, the KDE team released 4.5 after a one-week delay to fix some last minute bugs.

What can I say… that delay was worth the wait ;)

Upgrading a 4.4.4 to 4.5 (from suse build service, so unless you do it the same way, YMMV) was painless enough, and the result looks pretty, and feels a lot faster than 4.4.4.

On top of it, two major annoyances seem to have been fixed:

  • kopete doesn’t time out on you anymore if you donÄt enter the kwallet password fast enough
  • the icons on my desktop don’t rearrange themselves on each login.

good job, guys.

=-=-=-=-=
Powered by Blogilo

 

…actually, one change only, as far as I’ve discovered.

The openSUSE guys decided to drop SCPM from 11.3.

“Instead” there is network manager.

Whoever made that decision has no idea at all about what scpm is, and what you can do with it…

To make it short, NetworkManager does exactly that… it manages network connections, after the user has logged in.

SCPM stands for “System Configuration Profile Manager”… and it does exactly that… it manages system profiles… at boot time. You pick the profile you want right at the grub screen, and based on which of your profiles you choose the system replaces configuration files and runlevels and starts daemons or not.

As an example:

With Network Manager I can set up different configurations for my wireless network card.

With SCPM I can set up different configurations for my whole system… as in “in this configuration start the network card with dhcp, and start NIS, and start the automounter with NIS maps, and the time server is that, and the proxy is this, and the local hostname is whatever, and Oh i want runlevel 5 with kdm4 with that theme and this xorg.conf with 1680×1050 with the nvidia driver” versus “in that configuration, start the network so that the user can configure it with network manager. No NIS, no Automounter, runlevel 5 with a different theme because its the internal display at 1280×800, and automatically log in that user” versus “in this configuration, no network config at all, not even network manager, and text mode (runlevel 3).”

Or in short… replacing SCPM with NetworkManager is like replacing a whole kitchen with all appliances with one single spoon.

 

Just after we came back from our summer vacation I started upgrading a few computers to openSUSE 11.3, and I have to say, I found that to be pleasantly painless.

When I did that with 11.2, I found some major pains, but in 11.3, the "zypper dup" upgrade is officially supported, and "just works". So far I’ve done four machines, three of them had given me major headache when I upped them to 11.2 (as seen here).

With 11.3, the upgrade simply worked, seamless, even while still using the laptop in case for my daily work!

Now here are some few pros and cons that I’ve discovered so far:

The Pros

  • Like I said, you can upgrade a running system from 11.2 to 11.3 with the "zypper dup" approach described in the suse wiki. Take note to change EVERY repository to the 11.3 version, and disable/remove the ones that you won’t need.
  • Automatic X11 configuration works like a charm
  • The whole desktop (I’m using KDe 4.4.4 which is included with 11.3) feels very polished

The Cons

  • It took some time for the nvidia drivers to appear; without them the automatic X11 configuration would have failed, or rather, defaulted to that noveau driver which is not quite ready for use. Who in his right mind would include a driver at that state in a release.
  • SCPM config management will have to be redone in two cases… Time to rethink some settings anyways.
  • In one case I need a kernel parameter at boot time to disable the internal display of my lenovo laptop at work, because the thing doesn’t disable it from the bios if the laptop its in its docking station with the lid closed. Not exactly openSUSEs fault here.

Summary:

Go for it. It is good.

 

So now it’s been a few weeks since openSUSE 11.2 hit the street.

Here are a few impressions / factoids that i discovered so far:

  • upgrading through zypper with "zypper dup" as described on the openSUSE wiki: epic fail on 2 out of 3 tries. Both failed machines used the "desktop" kernel, maybe that is the reason.
  • upgrading from DVD through yast: works fine. BUT I also picked the "default" kernel right from the start so maybe that is what made the upgrade work.
  • clean install: no problems.
  • ext4 is damn fast in deleting huge subdirectories.
  • KDE4 needs to be upgraded to 4.3.4 to be usable; oSS is going to release 4.3.4 as a patchset for OSS 11.2 any day now.
  • the "desktop" kernel breaks openVPN. Not a good thing.

On the whole, openSUSE 11.2 is pretty good after you find the little tripping stones…

© 2009 Penguins and stuff - Ranting about LinuxSuffusion theme by Sayontan Sinha
Performance Optimization WordPress Plugins by W3 EDGE

Switch to our mobile site