Jeremy's Weblog

As of writing today, my Android powered phone (Droid X) cannot send SMS messages to some people, but receive messages fine. This is because my address book has “+1″ on some people’s numbers.

Solution: Add/edit a number without the “+1″ – in a connected world, I don’t even bother to “save” phone numbers, they get synced to me from third party sources (facebook). In this case, synced in such a way that it won’t work.

By the way, I tried the stock Android SMS program and Handcent SMS, both have the same trouble. Quite a hassle, but such is technology/software. Sigh.
(source: droidforums)

Scenario: You need to setup a service that requires ssh access to a remote host, possibly/probably by the root user. This service needs to run at regular intervals and it is critical that it works without a human entering a passphrase (even once).

Solution: The obvious solution that comes to mind is a ssh key. But a password-less key that allows root login? RED FLAG. However, there is a way to accomplish this without allowing a root login completely. That is to create, what I call, a single purpose key. I feel like this not a widely known trick, so I am archiving it so I don’t forget myself.

Details:
(Where local host is the host that needs ssh access and remote host is the host that you are “opening” up or allowing ssh access to)

1. On the local host, create a ssh key without a passphrase for the root user, this is widely documented via other sources
2. On the remote host, add the key to the /root/.ssh/authorized_keys file. However, start the line in that file with command="/root/bin/validate-ssh.sh"
3. On the remote host, the /root/bin/validate-ssh.sh script is a simple script that allows access to your service and exits for anything else. An example of allowing rsync access [only]:

   
   % cat /root/bin/validate-ssh.sh
   #!/bin/bash
   case "$SSH_ORIGINAL_COMMAND" in
   	rsync\ --server*)
   		# uncomment for debug
   		# echo "$(date +%Y%m%d): $SSH_ORIGINAL_COMMAND" >> /var/log/ssh-cmd.log
   		$SSH_ORIGINAL_COMMAND
   		;;
   	# debug
   	testconnect)
   		echo "You successfully connected to $(hostname)"
   		;;
   	*)
   		echo "Sorry, command '$SSH_ORIGINAL_COMMAND' is not allowed"
   		exit 1
   		;;
   esac
   

4. Optional, if you only want to allow this access from a small set of hosts add from="192.168.1.11,10.80.80.1" to the same line in /root/.ssh/authorized_keys

So, now, you can use that password-less ssh key as root (assuming the remote host allows root logins via ssh) and you should see something. ssh root@remote testconnect will return that string. rsync root@remote:/file will work. Everything else will get the message that indicates it wasn’t allowed. This is expandable to just about everything provided that you know the “$SSH_ORIGINAL_COMMAND” – on another host I use it to allow password-less sshfs access, so SSH_ORIGINAL_COMMAND=/usr/lib/misc/sftp-server and so-forth.

Naturally, this will work for other users/uses as well. I’ve seen references that some admins are using this to allow access if and only if they enter a sekrit token, etc. I’ll also say that you should be smart with this, opening up root access is a hole – if anyone compromises the local host, I suppose they could get access to the remote host if they knew how.

The problem:

% dmesg | grep -i micro
Atom PSE erratum detected, BIOS microcode update recommended
Atom PSE erratum detected, BIOS microcode update recommended
microcode: CPU0 sig=0x106c2, pf=0x4, revision=0x208
microcode: CPU1 sig=0x106c2, pf=0x4, revision=0x208
microcode: Microcode Update Driver: v2.00 , Peter Oruba

I found out that some recent kernel that I loaded at an unknown time, was able to point out that I had ‘old’ microcode for my processor on my Aspire1 ZG5. I searched around for a BIOS upgrade, but since this is an older generation netbook, I quickly gave up when my searching yielded nothing useful. There is a userspace tool that you can use to ‘upgrade’ the microcode provided by Intel on every boot. In Gentoo Linux, that is called sys-apps/microcode-ctl. Simply install that and enable the init script on boot.

The output after:

% dmesg | grep -i micro
Atom PSE erratum detected, BIOS microcode update recommended
Atom PSE erratum detected, BIOS microcode update recommended
microcode: CPU0 sig=0x106c2, pf=0x4, revision=0x208
microcode: CPU1 sig=0x106c2, pf=0x4, revision=0x208
microcode: Microcode Update Driver: v2.00 , Peter Oruba
microcode: CPU0 updated to revision 0x218, date = 2009-04-10
microcode: CPU1 updated to revision 0x218, date = 2009-04-10

References:

• https://wiki.archlinux.org/index.php/Microcode
• Flameeyes’s Weblog : Microupdates for microcodes

Edit: Added a reference

This post will probably annoy some people, or bring bad “spotlight” to Gentoo Linux. I call it a case study, but it is just my opinions…

The QA team has said that there is some sort of “policy” on masking packages that break reverse dependencies. I’ll subscribe that that policy for the sake of not breaking users machines on purpose, however, let’s take a look at the current case study: poppler-0.16

package.mask (in context, name removed because it isn’t needed):
+# Masked because of ABI change, breaks
+# depending packages. Keep masked until depended packages
+# got fixed (adjusted dependency or fixing version bump).
+# tracer bug 349918
+=app-text/poppler-0.16.0

…and there was some discussion on IRC. The QA team (at least a few members) says that the “tree is broken” with poppler-0.16. At time of this writing, 7 packages were reported on the tracker bug and 2 were fixed already. So, it is my opinion that progress for Gentoo is hampered because of this masking. I’ll explain why but first the different theories to package testing that I have observed.

Theory 1:
Run full arch for stability. The problem with this theory is that some group of people/machines need to test ~arch packages first and report issues, otherwise they will hit the stable users and the concept of the arch/~arch tree will break down. The advantage being less compilation in general, and the goal being stability or less breakage. I consider this theory for people that are new to Gentoo.

Theory 2:
Run full ~arch to find interaction issues. This is a fine theory, but not for me. Even though I am a Gentoo dev, I don’t have copious amounts of free time to contribute how I want if I am running ~arch. It is my personal opinion that users should not run full ~arch if they do not want to be bothered contributing back to gentoo/upstream, via bug reports, patches, etc. The advantage here, is that full ~arch users/machines will be able to find issues with the package before it is deemed “stable” – in theory, finding issues fast and being fixed fast. The downside being more compilation, occasional breakage, and/or random mistakes (devs are human, after-all). The Gentoo Handbook says that ~arch needs more testing and isn’t enabled by default. I’d consider this theory for power users. “I only want the latest packages” is no excuse for using this theory if you are going to complain about the above mentioned downsides.

Theory 3:
Run mostly arch and a few ~arch packages. This is what most of my machines run. That is, arch (stable) system and ~arch for packages that I maintain (or help maintain). The advantage here is what I consider real integration testing. The theory is that everything in ~arch will become arch, at one point. These ~arch packages are coming in one-by-one, so it makes no sense to only test a full ~arch tree if the package will be entering the arch tree. This is what the arch team does when they mark packages stable. The downside being, more management, maybe some dependency issues if they aren’t stated properly, etc. I’d consider this theory for people that prefer stability but enjoy the latest packages for some apps.

I think it is valuable to have a user base that is doing all of those theories. …back to poppler.

As we have seen in the past, once a package is “masked for testing” – it may take years to lift that mask because no one actually tests it. And why should you? It is masked and therefore not even in the testing category (~arch)!! Bingo, the crux of this case study. Technically speaking, there is nothing wrong with poppler-0.16.0, it is perfectly fine to be in ~arch by its own criteria. On the other hand, it’s ABI change breaks packages that haven’t been fixed to work with the new ABI yet. By masking a package that changes ABI with a soname change, it could (and should, in my opinion) be considered slowing progress for Gentoo. It should not be considered that the “[whole] tree is broken” – these 7 packages may just be the tip of the iceberg in the breakage category, but we won’t know if it is masked and users are not contributing. Let’s remind ourselves that the arch tree is still functioning properly at this point and “stable” users won’t see any issues…now. For them, thankfully, the ~arch users (including devs) are contributing to Gentoo via bug reports & patches. It should also be noted that nothing is being broke “on purpose” here, bugs are being filed and bugs are being fixed – this is the goal of a software project, right?

So, the way I see it, is a chain reaction.

1. Package enters the tree that causes a slight nuisance. 7/14205 known packages affected or 0.04 % of the tree.
2. The QA team deems this problem package as too severe to allow in ~arch and masks it. (Personal opinion is the 0.04% of the tree is not a servere problem)
3. The maintainer of the problem package is trying to identify breakages by leaving it in ~arch (and relying on the power users)
4. Since the package is masked, the effects of this problem package will be prolonged because “no one” will be testing it in ~arch.
5. The 7 affected packages are fixed, the problem package is unmasked
6. A new set of affected packages are found
7. repeat above

And now for some hard questions:

• How should Gentoo make it easier to add packages that break reverse dependencies if ~arch isn’t appropriate and nothing really happens when package.mask’d?
• Is ~arch becoming a second stable tree and thus losing value in general?
• Related, are overlays hurting Gentoo? The Xfce team subscribes to the theory that ~arch is the place to get useful testing feedback. The Xfce pre releases are in ~arch so the final release is ready for arch asap. This means that we have less work in the long run because we are maintaining less versions sooner and in better quality. The GNOME team subscribes to the theory that their overlay is for new releases and it takes longer to get packages in ~arch and thus longer to arch (my observation only, not official)
• portage-2.2 has this cool “preserved-libs” feature that wouldn’t help compilation issues in this case but might help runtime issues by keeping the old lib(s) around. I like this feature but it is still masked for majority of the users, even though many devs are using it – is it time to release it to the world with all the bugs it has?
• Related, does masking a feature block contributors? I want to say yes simply due to exposure.

Disclaimer: This was in NO WAY meant to be a personal attack against anyone. I can live with agreeing to disagree with people. But I can’t agree with not bringing something up because it is a controversial topic.

Xfce-4.8pre2 was announced yesterday. Gentoo has it available already thanks to the work of Samuli (ssuominen). The pre1 version was available with 0day bumps too, that proved to have the normal beta release “issues”, there are many bugs fixed in pre2 (ChangeLog). I saw several Gentoo users participating on the Xfce bugtracker, thanks. If you are of the type to test and report bugs, feel free to upgrade to 4.8pre2 and help make 4.8 final a solid release by participating upstream (bug tracker).

The final 4.8 release is scheduled for January 16th, 2011. The Gentoo Xfce team will continue to bring you 0day bumps if possible. The 4.8 series will not hit the Gentoo stable tree until after the final release.

The Gentoo Prefix project is still alive and still kicking. There has not been any major noteworthy highlights so you may not heard from us in some time. The number of users increases and the number of active contributors seems to stay the same or increase much more slowly. Gentoo Prefix was the reason I become a Gentoo Linux developer, so get involved..it is an easy gateway to being a Gentoo Developer if you are interested.

Some interesting things to note that I have been working on:

• My ~x86-linux binpkg repo for Gentoo Linux hosts is still running every night. I use this to easily find simple build errors in packages before they hit too many users.
• I started a ~amd64-linux binpkg repo to add coverage to my nightly automated testing. So, I’ve updated the instructions from the above post. This means that you can install your very own Gentoo Prefix installation on a Gentoo Linux host in 5 minutes for 32bit or 64 bit now.
• While those are updating everynight. I am now bootstrapping everynight too. I set up a small script that debootstraps a Debian Lenny chroot and then sets up an Gentoo Prefix inside the chroot. This will help finding bootstrapping bugs that brand new users may hit. Often times bootstrapping is more sensitive/fragile to tree changes than just updating.
• We are still migrating packages from the Gentoo Prefix tree to the Gentoo Linux tree. This is going slower than planned but there are not too many people working on it. Current: Over ~2000 packages migrated, still over 700 to go in our overlay. (Gentoo Prefix tree has over 7000 packages in it, but not all are tested/keyworded.)

There seems to be a semi-meme going around on some of the planets I read.

My concern is long directory paths and I wanted a dymanic solution for it. Surely, I cannot be the first person to think of it, but I haven’t seen it in use anywhere else.

jolexa @ helios :: ~ %%

and
jolexa @ helios :: ~ %% cd projects/prefix-tinderbox/really_long_dirname_so_that_binpkgs_can_be_shortened/a/b/
jolexa @ helios :: .../a/b %%

(the colors and wrapping are representitive only)

and the code that produces that:

_chomp_path() {
    local path=${1/${HOME}/\~}
    local last=${path} sedout= count=0 count2=0
    sedout=$(echo ${path} | sed -e 's:/: :g')
    for i in ${sedout}; do
        (( count++ ))
    done
    if ((count > 2)); then
        last="..."
        for i in ${sedout}; do
        (( count2++ ))
        if (( count2 >=  count - 1 )); then
            last+="/$i"
        fi
        done
    fi
    echo ${last}
}

PS1='\[\033[1;34m\]\u \[\033[1;32m\]@\[\033[1;34m\] \h \[\033[1;30m\]::\[\033[1;37m\] $(_chomp_path $(pwd)) \[\033[1;30m\]%%\[\033[0m\] '

If anyone wants to improve that function, let me know. It “fails” on directories with spaces in it.

It should be no secret that this site and my other co-location needs are hosted at Linode.com, for which I am a happy customer running Gentoo Linux.

The reason for this post is that after an announcement today. All I had to do was reboot and then I received a 42% RAM increase. Yay.

Thanks Linode, you are exceeding your competition!
(Shameless plug for my referral code )