TL;DR: How lazy can you be? This post should take you 5 minutes to read... :-P

So npm is out of Debian testing. This means that the hell that is node code handling is now even harder. node's installation instructions is a bloody video from which you can't copy and paste the commands (how useful), and as far as I can tell, it's the official way to install npm.

If you already have a good version of node provided by your trusted distribution, you most probably will cringe on the idea of installing a third party package like this, and probably you don't think containers are the solution, or you just want to install something locally so you can play with it.

If you look closer to the bottom of that page you'll find the "advances user's" guide to install it yourself, but it's only a pattern URL to the distribution .tar.gz, with no further instructions. With a little bit of luck, the instructions will be included. The pattern has a placeholder for the version you want (putatively, the latest), but I can't find, for the life of me, references to which is the latest version.

In the GitHub project page you will find the terrible, unluckily classic curl https://site.com/unknown_script.sh | sh command that downloads this script. The script is in POSIX shell dialect, and has strange constructions:

node=`which node 2>&1`
ret=$?
if [ $ret -eq 0 ] && [ -x "$node" ]; then
  (exit 0)

To me, that exit 0 in a subshell is the equivalent of a NOOP, so I wonder why they decided to write the condition like that.

After checking the availability of a couple of tools (node, tar, make, but not curl), it uses the latter to download JSON from the registry, finding there the actual version (currently 4.5.0, if you're interested). It downloads the package, untars it, and executes:

"$node" cli.js rm npm -gf
"$node" cli.js install -gf

The first removes any old installation. More on that in a minute. The second, obviously, installs the new version. But the -gf options (I hate short options in scripts) are to be guessed, as no help is provided about them. Let's go with --global and --force, which means it will install somewhere in your system and overwriting anything it finds. With the previous command it should have deleted all the files (same options), so you're really nuking whatever was there before.

Nowhere in the instructions so far says anything about root, but obviously this needs to be run as such. There's also this detail:

As of version 0.3, it is recommended to run npm as root. This allows npm to
change the user identifier to the nobody user prior to running any package
build or test commands.

So there's no way to make a local installation of npm... is there? Well, not user wide, only system wide (already explained) and project wide. Here's how to do the latter:

$ wget https://registry.npmjs.org/npm/-/npm-4.5.0.tgz
$ tar xvf npm-4.5.0.tgz  # it's unpacked in a directory called 'package'
$ /usr/bin/node package/cli.js install npm
$ rm -rf package  # clean up after you!
$ ./node_modules/.bin/npm install carto

The third command uses the tarball's CLI interface to install the same version 'the right way'. To be honest, I had already used the old npm version that used to come with Debian to do exactly the same thing. Of course, this works as long as newer version of npm can still be installed with such an old version of the same. Who knows when that's gonna break/be deprecated.

All in all, it's sad to see such an useful tool be dropped like that. I just hope someone can pick up the pieces.


debian nodejs npm

Posted jue 04 may 2017 21:58:58 CEST Tags: debian

Nice tricks I found out trying to unfuck my laptop's setup, all my fault:

  • You can use snapshot.debian.org to recover packages for any date for any release that was available at that date. I actually new this, but somehow I forgot. I used deb http://snapshot.debian.org/archive/debian/20150720T214439Z/ testing main.

  • For that you have to disable the Packages-file-too-old check, which I have never seen, ever. Put this in any file in your /etc/apt.conf.d dir:

Acquire {
    Check-Valid-Until "false";
}
  • aptitude has a menu bar (activate with C-t), a preferences dialog, and you can set it up so any operation with a package moves down the cursor. Finally I figure that out.

  • It also has a dselect theme, but I was not brave enough to try it (for the record, I love dselect, I miss the fact that it shows how dependencies are resolved in the moment they're needed).

  • You can disable aptitude's resolver (-o Aptitude::ProblemResolver::StepLimit=0), but it doesn't make the UI that much more responsive (???).

  • digikam is not on testing right now. It FTBFS with gcc5 and has a licence problem.

  • Don't ride Debian sid right now, it's suffering a gcc transition and it might take a while.


debian

Posted lun 31 ago 2015 20:46:27 CEST Tags: debian

On November 26, the Qt/KDE Debian team (qkd from now on) released an experimental packaging of KDE SC 4.7. This means a substantial and very much awaited upgrade from the actual version available in sid, 4.6.5 . From what I've been told, it has taken so long because there have been a lot of changes in source code structure (KDE has recently restructured its source modularization) and in packaging itself, and even with recent aditions to the group, the resources in terms of developers is still low. In any case, thanks to them for getting this version out, I really appreciate your hard work.

But because of this lack of resources, they only got out packages for the amd64 architecture, and I'm running i386 at home, so I decided to try and compile it by myself. This is the log of the attempt.

First, I added deb-src http://qt-kde.debian.net/debian experimental-snapshots main to my sources.list and got the code for kde4libs, the package I think is the root of the whole repo[1][2]:

mdione@mustang:~/src/system/debian$ apt-get source kde4libs
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'kde4libs' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/pkg-kde/kde-sc/kde4libs.git
Need to get 12.4 MB of source archives.
Get:1 http://qt-kde.debian.net/debian/ experimental-snapshots/main kde4libs 4:4.7.2-0r3 (dsc) [4,883 B]
Get:2 http://qt-kde.debian.net/debian/ experimental-snapshots/main kde4libs 4:4.7.2-0r3 (tar) [12.1 MB]
Get:3 http://qt-kde.debian.net/debian/ experimental-snapshots/main kde4libs 4:4.7.2-0r3 (diff) [334 kB]
Fetched 12.4 MB in 1min 54s (109 kB/s)
gpgv: Signature made Sat 22 Oct 2011 02:29:45 AM CEST using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./kde4libs_4.7.2-0r3.dsc
dpkg-source: info: extracting kde4libs in kde4libs-4.7.2
dpkg-source: info: unpacking kde4libs_4.7.2.orig.tar.bz2
dpkg-source: info: unpacking kde4libs_4.7.2-0r3.debian.tar.gz
dpkg-source: info: applying kconf_update_migrate_from_kde3_icon_theme.diff
dpkg-source: info: applying add_debian_build_type.diff
dpkg-source: info: applying disable_usr_lib_install_rpath.diff
dpkg-source: info: applying make_libkdeinit4_private.diff
dpkg-source: info: applying default_kde4_xdg_menu_prefix.diff
dpkg-source: info: applying qt4_designer_plugins_path.diff
dpkg-source: info: applying hardcode_ptm_device.diff
dpkg-source: info: applying kfreebsd_support.diff
dpkg-source: info: applying debian_menu.diff
dpkg-source: info: applying findservicebydesktoppath_try_realfilepath.diff
dpkg-source: info: applying findqt4_optional_x11_pthread.diff
dpkg-source: info: applying use_dejavu_as_default_font.diff
dpkg-source: info: applying hack_in_etc_kde4_in_kstandarddirs.diff
dpkg-source: info: applying ld_exclude_libs_qtuitools.diff
dpkg-source: info: applying konsole_kfreebsd_fix.diff
dpkg-source: info: applying hurd_support.diff
dpkg-source: info: applying kfileshare_kdesu_fileshareset.diff
dpkg-source: info: applying relax_plugin_kde_version_check.diff
dpkg-source: info: applying add_dlrestrictions_support.diff
dpkg-source: info: applying findpythonlibrary_layout_deb_on_debian.diff
dpkg-source: info: applying ktar_header_checksum_fix.diff
dpkg-source: info: applying ktar_longlink_length_in_bytes.diff
dpkg-source: info: applying nepomuk_unicode.diff

Nice, now get the build-deps:

mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kde4libs
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Build-Depends dependency for kde4libs cannot be satisfied because candidate version of package shared-desktop-ontologies can't satisfy version requirements

Dang, I have an old shared-desktop-ontologies (v. 0.6.x in sid), and peeking in qkd's repo I find no new version of it. The answer must be in experimental, so I add deb http://ftp.nl.debian.org/debian/ experimental main to my sources.list and run apt-get update. Now it must be just a matter of:

mdione@mustang:~/src/system/debian$ sudo apt-get install -t experimental shared-desktop-ontologies
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  shared-desktop-ontologies
1 upgraded, 0 newly installed, 0 to remove and 103 not upgraded.
Need to get 129 kB of archives.
After this operation, 4,096 B of additional disk space will be used.
Get:1 http://ftp.nl.debian.org/debian/ experimental/main shared-desktop-ontologies all 0.8.0-1 [129 kB]
Fetched 129 kB in 1s (92.7 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for mustang
(Reading database ... 218251 files and directories currently installed.)
Preparing to replace shared-desktop-ontologies 0.6.0-1 (using .../shared-desktop-ontologies_0.8.0-1_all.deb) ...
Unpacking replacement shared-desktop-ontologies ...
Setting up shared-desktop-ontologies (0.8.0-1) ...

And I try again:

mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kde4libs
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  hspell libacl1-dev libattica-dev libattr1-dev libdbusmenu-qt-dev libdlrestrictions-dev libpolkit-qt-1-dev libqca2-dev libstreamanalyzer-dev libstreams-dev
  libutempter-dev pkg-kde-tools
0 upgraded, 12 newly installed, 0 to remove and 8 not upgraded.
Need to get 1,170 kB of archives.
After this operation, 3,551 kB of additional disk space will be used.
Do you want to continue [Y/n]?
[...]

We're set! now to fire the compilation itself. The method I use must not be the best one, but I remember it by heart and works for me :)

mdione@mustang:~/src/system/debian$ cd kde4libs-4.7.2/
mdione@mustang:~/src/system/debian/kde4libs-4.7.2$ nice -n 19 fakeroot debian/rules binary

Notice I use nice to not hog too much my computer and fakeroot. I don't remember why I must use it :| , but I remember I must. Later, asking in #debian-devel I was pointed to dpkg-buildpackage, to which you can give the -j# option, which makes the package to be compiled with # processes in parallel (actually it only works if the compilation is make based, as is in this case), so from now on I'll use that.

The resulting packages are these:

kdelibs5-data_4.7.2-0r3_all.deb
kdelibs5-dbg_4.7.2-0r3_i386.deb
kdelibs5-dev_4.7.2-0r3_i386.deb
kdelibs5-plugins_4.7.2-0r3_i386.deb
kdelibs-bin_4.7.2-0r3_i386.deb
kdoctools_4.7.2-0r3_i386.deb
libkcmutils4_4.7.2-0r3_i386.deb
libkde3support4_4.7.2-0r3_i386.deb
libkdeclarative5_4.7.2-0r3_i386.deb
libkdecore5_4.7.2-0r3_i386.deb
libkdesu5_4.7.2-0r3_i386.deb
libkdeui5_4.7.2-0r3_i386.deb
libkdewebkit5_4.7.2-0r3_i386.deb
libkdnssd4_4.7.2-0r3_i386.deb
libkemoticons4_4.7.2-0r3_i386.deb
libkfile4_4.7.2-0r3_i386.deb
libkhtml5_4.7.2-0r3_i386.deb
libkidletime4_4.7.2-0r3_i386.deb
libkimproxy4_4.7.2-0r3_i386.deb
libkio5_4.7.2-0r3_i386.deb
libkjsapi4_4.7.2-0r3_i386.deb
libkjsembed4_4.7.2-0r3_i386.deb
libkmediaplayer4_4.7.2-0r3_i386.deb
libknewstuff2-4_4.7.2-0r3_i386.deb
libknewstuff3-4_4.7.2-0r3_i386.deb
libknotifyconfig4_4.7.2-0r3_i386.deb
libkntlm4_4.7.2-0r3_i386.deb
libkparts4_4.7.2-0r3_i386.deb
libkprintutils4_4.7.2-0r3_i386.deb
libkpty4_4.7.2-0r3_i386.deb
libkrosscore4_4.7.2-0r3_i386.deb
libkrossui4_4.7.2-0r3_i386.deb
libktexteditor4_4.7.2-0r3_i386.deb
libkunitconversion4_4.7.2-0r3_i386.deb
libkutils4_4.7.2-0r3_i386.deb
libnepomuk4_4.7.2-0r3_i386.deb
libnepomukquery4a_4.7.2-0r3_i386.deb
libnepomukutils4_4.7.2-0r3_i386.deb
libplasma3_4.7.2-0r3_i386.deb
libsolid4_4.7.2-0r3_i386.deb
libthreadweaver4_4.7.2-0r3_i386.deb

Next package is kadebase. Again, we find the missing deps with:

mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kdebase
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Build-Depends dependency for kdebase cannot be satisfied because candidate version of package kde-sc-dev-latest can't satisfy version requirements

The message is simlar to the one about shared-desktop-ontologies, but I have not even the slightest idea which one of the packages above is the one responsible for it, so I'll just install everything, as most probably they're build-deps for most of the remaining packages (it's kde5libs, after all):

mdione@mustang:~/src/system/debian$ sudo dpkg -i *.deb
(Reading database ... 218481 files and directories currently installed.)
[...]

After that I try again, but still the same thing. Poking around I find that a package with that name exists (it's the first time I met him, enchanté), so I get the source in the usual way:

mdione@mustang:~/src/system/debian$ apt-get source meta-kde
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 14.0 kB of source archives.
Get:1 http://qt-kde.debian.net/debian/ experimental-snapshots/main meta-kde 5:71~pre15 (dsc) [2,098 B]
Get:2 http://qt-kde.debian.net/debian/ experimental-snapshots/main meta-kde 5:71~pre15 (tar) [11.9 kB]
Fetched 14.0 kB in 0s (49.3 kB/s)
gpgv: Signature made Mon 21 Nov 2011 09:38:12 PM CET using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./meta-kde_71~pre15.dsc
dpkg-source: info: extracting meta-kde in meta-kde-71~pre15
dpkg-source: info: unpacking meta-kde_71~pre15.tar.gz

And to compile:

mdione@mustang:~/src/system/debian$ ( cd meta-kde-71~pre15 && nice -n 19 dpkg-buildpackage -j3 -b -us -uc )
dpkg-buildpackage: source package meta-kde
dpkg-buildpackage: source version 5:71~pre15
dpkg-buildpackage: source changed by Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
dpkg-buildpackage: host architecture i386
[...]

That generates several packages, but I just install the one I want:

mdione@mustang:~/src/system/debian$ sudo dpkg -i kde-sc-dev-latest_4.7.2+5.71~pre15_all.deb
Selecting previously unselected package kde-sc-dev-latest.
(Reading database ... 218469 files and directories currently installed.)
Unpacking kde-sc-dev-latest (from kde-sc-dev-latest_4.7.2+5.71~pre15_all.deb) ...
Setting up kde-sc-dev-latest (4:4.7.2+5.71~pre15) ...

Now the build-deps again:

mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kdebase
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  libkatepartinterfaces4
The following NEW packages will be installed:
  libqimageblitz-dev libtidy-dev
0 upgraded, 2 newly installed, 1 to remove and 8 not upgraded.
Need to get 205 kB of archives.
After this operation, 1,932 kB disk space will be freed.
Do you want to continue [Y/n]?
[...]

You'll probably won't notice (as I didn't) that it has removed a package, libkatepartinterfaces. This is because in my system I have the old version of it and there seems to be some kind of conflict somewhere. I just cross my fingers it won't break much[3].

Now get the sources and compile:

mdione@mustang:~/src/system/debian$ apt-get source kdebase
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'kdebase' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/pkg-kde/kde-sc/kdebase.git
Need to get 2,721 kB of source archives.
Get:1 http://qt-kde.debian.net/debian/ experimental-snapshots/main kdebase 4:4.7.1-0r2 (dsc) [3,217 B]
Get:2 http://qt-kde.debian.net/debian/ experimental-snapshots/main kdebase 4:4.7.1-0r2 (tar) [2,685 kB]
Get:3 http://qt-kde.debian.net/debian/ experimental-snapshots/main kdebase 4:4.7.1-0r2 (diff) [33.1 kB]
Fetched 2,721 kB in 26s (105 kB/s)
gpgv: Signature made Tue 27 Sep 2011 09:43:53 PM CEST using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./kdebase_4.7.1-0r2.dsc
dpkg-source: info: extracting kdebase in kdebase-4.7.1
dpkg-source: info: unpacking kdebase_4.7.1.orig.tar.bz2
dpkg-source: info: unpacking kdebase_4.7.1-0r2.debian.tar.gz
dpkg-source: info: applying enable_debianabimanager.diff
dpkg-source: info: applying enable_dlrestrictions.diff

mdione@mustang:~/src/system/debian$ ( cd kdebase-4.7.1 && nice -n 19 dpkg-buildpackage -j3 -b -us -uc )
[...]

Installing the resulting packages is another history, as some of them depend on kde-runtime, so it's better if you compile kde-runtime before[4]. Trying to install its build-deps, you realize taht you actually need to compile soprano first.

You get the idea. Now I'll just show the generated packages I installed by hand after each compilation, but only those that suited my needs:

soprano:

mdione@mustang:~/src/system/debian$ sudo dpkg -i \
soprano-daemon_2.7.3+dfsg.1-0r0_i386.deb \
libsoprano4_2.7.3+dfsg.1-0r0_i386.deb \
libsoprano-dev_2.7.3+dfsg.1-0r0_i386.deb

kde-runtime:

mdione@mustang:~/src/system/debian$ sudo dpkg -i \
kdebase-runtime_4.7.2-0r3_all.deb \
khelpcenter4_4.7.2-0r3_i386.deb \
kde-config-phonon-xine_4.7.2-0r3_i386.deb \
kde-runtime-data_4.7.2-0r3_all.deb \
kde-runtime_4.7.2-0r3_i386.deb \
plasma-scriptengine-javascript_4.7.2-0r3_i386.deb

While installing kde-runtime-data I had to remove kdebase-runtime-data:

[...]
Selecting previously unselected package kde-runtime-data.
dpkg: regarding kde-runtime-data_4.7.2-0r3_all.deb containing kde-runtime-data:
 kde-runtime-data breaks kdebase-runtime-data (<< 4:4.7.2)
  kdebase-runtime-data (version 4:4.6.5-1) is present and installed.
[...]

mdione@mustang:~/src/system/debian$ sudo dpkg --remove kdebase-runtime-data
(Reading database ... 218612 files and directories currently installed.)
Removing kdebase-runtime-data ...
[...]

kdebase:

mdione@mustang:~/src/system/debian$ sudo dpkg -i \
dolphin_4.7.1-0r2_i386.deb \
kdebase-bin_4.7.1-0r2_i386.deb \
kdebase-data_4.7.1-0r2_all.deb \
kdepasswd_4.7.1-0r2_i386.deb \
konq-plugins_4.7.1-0r2_i386.deb \
konqueror_4.7.1-0r2_i386.deb \
konqueror-nsplugins_4.7.1-0r2_i386.deb \
libkonq5abi1_4.7.1-0r2_i386.deb \
libkonq-common_4.7.1-0r2_i386.deb \
plasma-widget-folderview_4.7.1-0r2_i386.deb

While trying to get akonadi I got this error message:

Failed to fetch http://qt-kde.debian.net/debian/pool/main/a/akonadi/akonadi_1.6.2-0r1.dsc  Hash Sum mismatch

Checking the MD5, SHA1 and SHA256 checksums and comparing to the ones in the .dsc file revealed no difference. lisandro told me to use dget instead:

mdione@mustang:~/src/system/debian$ dget http://qt-kde.debian.net/debian/pool/main/a/akonadi/akonadi_1.6.2-0r1.dsc
dget: retrieving http://qt-kde.debian.net/debian/pool/main/a/akonadi/akonadi_1.6.2-0r1.dsc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2620  100  2620    0     0   6842      0 --:--:-- --:--:-- --:--:--  8161
dget: using existing akonadi_1.6.2.orig.tar.bz2
dget: using existing akonadi_1.6.2-0r1.debian.tar.gz
akonadi_1.6.2-0r1.dsc:
dscverify: akonadi_1.6.2-0r1.dsc failed signature check:
gpg: Signature made Thu 03 Nov 2011 08:55:52 AM CET using RSA key ID 73A85F31
gpg: Can't check signature: public key not found
Validation FAILED!!

Unpacking by hand:

mdione@mustang:~/src/system/debian$ dpkg-source -x akonadi_1.6.2-0r1.dsc
gpgv: Signature made Thu 03 Nov 2011 08:55:52 AM CET using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./akonadi_1.6.2-0r1.dsc
dpkg-source: info: extracting akonadi in akonadi-1.6.2
dpkg-source: info: unpacking akonadi_1.6.2.orig.tar.bz2
dpkg-source: info: unpacking akonadi_1.6.2-0r1.debian.tar.gz
dpkg-source: info: applying x11_not_required.diff

akonadi:

mdione@mustang:~/src/system/debian$ sudo dpkg -i \
akonadi-server_1.6.2-0r1_i386.deb \
akonadi-backend-sqlite_1.6.2-0r1_i386.deb \
libakonadi-dev_1.6.2-0r1_i386.deb \
libakonadiprotocolinternals1_1.6.2-0r1_i386.deb

Here I cheated: I really didn't want to spend 10 minutes of iterative attempts to find the minimal set of lib packages to install:

libkdepim:

mdione@mustang:~/src/system/debian$ sudo dpkg -i \
kdepimlibs5-dev_4.7.2-0r1_i386.deb \
kdepimlibs-kio-plugins_4.7.2-0r1_i386.deb \
lib*.deb

kde-wallpapers:

mdione@mustang:~/src/system/debian$ sudo dpkg -i \
kde-wallpapers-default_4.7.2-0r0_all.deb

kde-workspace:

sudo dpkg -i --auto-deconfigure \
systemsettings_4.7.2-0r7_i386.deb \
plasma-desktop_4.7.2-0r7_i386.deb \
plasma-scriptengine-python_4.7.2-0r7_all.deb \
plasma-widgets-workspace_4.7.2-0r7_i386.deb \
plasma-dataengines-workspace_4.7.2-0r7_i386.deb \
klipper_4.7.2-0r7_i386.deb \
kdm_4.7.2-0r7_i386.deb \
kde-workspace-bin_4.7.2-0r7_i386.deb \
kde-workspace-data_4.7.2-0r7_all.deb \
kde-window-manager_4.7.2-0r7_i386.deb \
kdebase-workspace_4.7.2-0r7_all.deb \
kdebase-workspace-bin_4.7.2-0r7_all.deb \
libkworkspace4_4.7.2-0r7_i386.deb \
kde-workspace-kgreet-plugins_4.7.2-0r7_i386.deb \
kde-style-oxygen_4.7.2-0r7_i386.deb \
libkdecorations4_4.7.2-0r7_i386.deb \
libkephal4abi1_4.7.2-0r7_i386.deb \
libkwineffects1abi2_4.7.2-0r7_i386.deb \
libkworkspace4_4.7.2-0r7_i386.deb \
libplasmagenericshell4_4.7.2-0r7_i386.deb \
libtaskmanager4abi2_4.7.2-0r7_i386.deb \
libplasmaclock4abi2_4.7.2-0r7_i386.deb \
libksgrd4_4.7.2-0r7_i386.deb \
libplasma-geolocation-interface4_4.7.2-0r7_i386.deb \
libsolidcontrol4abi2_4.7.2-0r7_i386.deb \
libprocesscore4abi1_4.7.2-0r7_i386.deb \
libweather-ion6_4.7.2-0r7_i386.deb \
libkscreensaver5_4.7.2-0r7_i386.deb \
libprocessui4a_4.7.2-0r7_i386.deb \
libsolidcontrolifaces4abi2_4.7.2-0r7_i386.deb \
kde-workspace_4.7.2-0r7_all.deb \
ksysguard_4.7.2-0r7_i386.deb \
freespacenotifier_4.7.2-0r7_i386.deb \
libksignalplotter4_4.7.2-0r7_i386.deb \ 
ksysguardd_4.7.2-0r7_i386.deb

I'll just finish this post here. The rest is just more of the same. The final list of packages a compile in right order is:

kde4libs
meta-kde
soprano
kde-runtime
kdebase
akonadi
prison
kdepimlibs
kde-wallpapers
kde-workspace

All in all, this took some 10 hours of finding deps, compiling and installing, and 6.4 GiB between original .tar.gz files, compilation dirs and generated packages.


[1] It's nice that I don't need to compile libqt4*, those take ages[5].

[2] Later lisandro from qkd pointed me to the dependency graph that confirms my guess.

[3] I did all this while running a KDE SC 4.6.5 session, and even writing this post in kate. Thanks to Linux and Debian not much actually broke, I only lost the ability to browse with konqueror after I installed the first batch of packages because KIO could not instantiate an HTTP/HTTPS ioslave anymore.

[4] Note that the dependency graph two notes above is actually a build dependency graph.

[5] Not that this compilation was fast. kdelibs without parallelism took some 3h and kdepimlibs and kde-workspace are two huge beasts.


debian kde

Posted dom 27 nov 2011 23:18:21 CET Tags: debian

Today I decided to upgrade my home server (the one that serves this blog) from lenny to squeeze. Here is a 'log' of the experience.

My first mistake was on the name: it is not squeezy, it's squeeze.

Second, the server once was also a minimal desktop, so I deinstalled a lot of desktop soft to make the upgrade smaller and easier. I simply used my favorite package manipulation toll, dselect[1], and selected for purging all the optional and extra packages in sections libs, python and perl. When the consequences where shown to me, I just marked as install the software I wanted. After that, ~450 packages where removed.

Following the release notes, and after checking the known upgrade issues, I did the first suggested step: a minimal upgrade.

mdione@cobra:~$ sudo apt-get upgrade
[...]
233 upgraded, 0 newly installed, 0 to remove and 142 not upgraded.
Need to get 67.2MB of archives.
After this operation, 11.5MB of additional disk space will be used.
[...]

I have apt-listbugs installed, so I got this question just before accepting the upgrade:

serious bugs of libslang2 (2.1.3-3 -> 2.2.2-4) <marked as done in some version>
 #615909 - Copyright file does not clearly state licence terms (Fixed: slang2/2.2.3-1)
serious bugs of deborphan (1.7.27 -> 1.7.28.3) <marked as done in some version>
 #618895 - orphaner enteres infinite loop on sparc (Fixed: deborphan/1.7.28.4)
critical bugs of initscripts (2.86.ds1-61 -> 2.88dsf-13.1) <unfixed>
 #612594 - On boot thw wait have no job to wait for, and fail into reboot.
serious bugs of libpcre3 (7.8-2 -> 8.02-1.1) <unfixed>
 #616660 - /usr/bin/pcretest must not be shipped in libpcre3
Summary:
 libpcre3(1 bug), libslang2(1 bug), deborphan(1 bug), initscripts(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...]

The critical bug for initscripts looked ugly, so I checked it in more depth. It seemed to affect usplash, which I don't use (no use in a headless server, right?), so I bit the bullet and continued. The bug's discussion said that the solution was to purge usplash anyways... The rest of the bugs were, pragmatically talking, not interesting to me.

Then apt-listchanges showed me the unread entries in the NEWS.Debian.gz files for the upgraded packages, with no news that applied to my server. Interesting was the split of pam_cracklib into itself and pam_pwhistory, so now we can test the reuse of passwords without checking for dictionary attacks, in the strange case one would want to do so, or the other way around. That means that if you want both, you got to enable both.

Besides some conffile resolution (it would be nice to be able to resolve diff with meld or xxdiff), the upgrade went smooth.

Upgrading the kernel was painless too. The kernel NEWS included a note on PATA devices rename due to the new SCSI/PATA drivers, but I was aware of that because I read about the upgrade issues first :) I just had to tell linux-base to please update the disk devices in my config files, which is the default anyways.

udev was a little bit more bumpy:

critical bugs of udev (0.125-7+lenny3 -> 164-3) <unfixed>
 #593083 - udev - system hangs at login screen
serious bugs of util-linux (2.13.1.1-1 -> 2.17.2-9) <unfixed>
 #613592 - /sbin/fdisk: Can't create at sector 63
 #613589 - /sbin/cfdisk: Bad Table error after fresh Squeeze install

The first one seemed to be something quite handlable, and the other two were not interesting to me. The bullet just needed a little bit more of squeezing, that's all (Hahahahaaa! I told a joke! I can do this crap too![2]).

For the last step I used dselect again, as I love the way it presents dependency resolution. I took the opportunity to purge all the obsolete packages, and I got no dependency problem with that, which means the upgrade should be complete and smooth. This last step meant:

128 upgraded, 68 newly installed, 32 to remove and 0 not upgraded.
Need to get 96.5MB of archives.
After this operation, 33.1MB disk space will be freed.

Yeah, smooth indeed, except for these:

serious bugs of wget (1.11.4-2+lenny2 -> 1.12-2.1) <marked as done in some version>
 #614373 - wget: mixes dpatch and 3.0 (quilt) (Fixed: wget/1.12-3)
serious bugs of lvm2 (2.02.39-8 -> 2.02.66-5) <marked as done in some version>
 #603710 - root and swap devices on lvm do not correctly show up in udev (missing symlinks) (Fixed: lvm2/2.02.84-1)
   Merged with: 593625
serious bugs of libgssapi-krb5-2 ( -> 1.8.3+dfsg-4) <marked as done in some version>
 #611906 - GSSAPI in krb5 1.8 fails to delegate credentials to W2K8R2 (Fixed: krb5/1.8.3+dfsg-5)
grave bugs of libdpkg-ruby1.8 (0.3.2 -> 0.3.6+nmu1) <unfixed>
 #585448 - Leaves files open as it scans, resulting in too many open files
   Merged with: 600260
grave bugs of dash (0.5.4-12 -> 0.5.5.1-7.4) <unfixed>
 #540512 - dash upgrade breaks mksh-as-/bin/sh
 #538822 - dash fails to upgrade if /bin/sh is locally diverted
grave bugs of grub-pc ( -> 1.98+20100804-14) <unfixed>
 #593648 - grub-pc install fails on RAID1 (unknown filesystem)
 #590884 - grub-pc: upgrading with vmlinuz-2.6.32-5-amd64 kernel fails on device detection
 #612220 - after update to squeeze grub2 don't load the system
 #620663 - grub-pc hangs after upgrading lenny to squeezy
grave bugs of openssh-client (1:5.1p1-5 -> 1:5.5p1-6) <unfixed>
 #607267 - /usr/bin/scp: fails to notice close() errors
grave bugs of elinks (0.12~pre2.dfsg0-1 -> 0.12~pre5-2) <unfixed>
 #617713 - Caches documents in violation of HTTP spec and general sanity
serious bugs of apt (0.7.20.2+lenny2 -> 0.8.10.3) <unfixed>
 #558784 - apt: re-adds removed keys
serious bugs of python2.5 (2.5.2-15+lenny1 -> 2.5.5-11) <unfixed>
 #598372 - python2.5: uses the network during build
serious bugs of lvm2 (2.02.39-8 -> 2.02.66-5) <unfixed>
 #603036 - lvm2: fails to install due to incorrect dependencies in init.d LSB header
serious bugs of munin (1.2.6-10~lenny2 -> 1.4.5-3) <unfixed>
 #619399 - munin shouldn't recreate apache conf on every update
serious bugs of grub (0.97-47lenny2 -> 0.97-64) <unfixed>
 #594283 - grub: non-standard gcc/g++ used for build (gcc-4.3)
serious bugs of insserv ( -> 1.14.0-2) <unfixed>
 #598020 - barfs when there are "invalid" init scripts

I focused on grub-pc bugs, because I don't have a monitor and having the server unbootable is not my idea of a funny way to spend my afternoon. 612220 and 620663 seemed the most graves ones, so I checked them. The latter seems more complicated, so I just added another bullet in my mouth and continued. The rest of the bugs seemed harmless enough for me. The NEWS had nothing either. The moment of truth was coming closer.

During the Debconf part, I chose to put grub-pc in the boot sector of the root partition and chainload it from grub-legacy which is still installed in the MBR. I also kept the old kernel, just in case.

With a mouthfull of bullets in different states of chewedness, I rebooted the server. As spected, nothing happened; that is, it booted fine, no problems, all services still there. Dissapointed, now I' looking intently to a more complicated server for an upgrade.

sysadmin debian


[1] yes, I know dselect is in maintenance mode now, and that it knows nothing about automatic packages, but I mostly know what I need and what not. In any case, what's missing can be installed later. Nothing critical is run in this server.

[2] If you hadn't, you really have to see Ahmed, the suicide terrorist

Posted mi� 06 abr 2011 20:12:16 CEST Tags: debian

Recently I had to do something that sounds very simple to any good SysAdmin: create a disk image with a booting Debian installation, from a script, with no human interaction. The idea is to later install our software on it. Those who want to test out soft would just need to download the image and boot it in any virtual machine they have: qemu, virtualbox[1], you name it.

So the process could be thought as this: create a disk image, partition it, install Debian, install a bootloader, profit! Let's try to tackle them separately, looking at different approaches[2]:

A disk image is simply a file big enough: 1GiB, 10GiB, whatever you want. A string of 1Gi of 0s should be enough:

dd bs=$((1024*1024)) count=1024 if=/dev/zero of=stable.img

Now, that file is using 1GiB of space, but we're not sure if we're going to use it all, and so is kinda a waste of space. Luckly, Linux is able to handle sparse files: files that do not reserve all the file system blocks would normally be needed, only those where data is written. So for instance, a way to create a 1GiB (almost) empty sparse file is this:

dd bs=1 count=1 seek=$((1024*1024*1024)) if=/dev/zero of=stable.img

That is, we write a 0 at the end of a 1GiB file[3], but even if the file is so big, it's actually using one file system block (4096 bytes, according to dumpe2fs).

A simpler, or maybe more-intuitive-when-you-read-it[4] alternative is to use a tool that comes in qemu-utils[A]:

qemu-img create -f raw stable.img 1G

That was easy. Now, how do we partition it? The first answer it's obvious, namely, fdisk, but it is not scriptable. So we look for alternatives, and one that comes to mind is parted: it is designed with scriptability in mind, it should be perfect!

Almost. parted needs a partition table signature in the MBR[5] and it has no way to create one. This is at least surprising, but a little more (ab)use of dd can save the day. It's just a matter of writing the bytes 0x55 0xaa[8] in the last two bytes of the first sector of the image. A disk sector, up to recently, is just 512 bytes, so:

echo -e "\x55\xaa" | dd bs=1 count=2 seek=510 of=stable.img conv=notrunc

The notrunc is so dd doesn't truncate the image to be 512 bytes long (it took me a while figuring that out). Now to parted:

parted -s stable.img mkpart primary ext2 0 1G
Warning: The resulting partition is not properly aligned for best performance.

But this will rise a problem that I'll mention later, at its proper time. So instead, and given that we're gonna install another package anyways, we're gonna use sfdisk[6][7]:

sfdisk -D stable.img <<EOF
,,L,*
;
;
;
EOF

The next step is to format the partition inside the image. If this were a partition image we could simply apply mkfs.ext2 (or whatver filesystem type you want) to the file, because the filesystem would start from the beginning of the file. But as this is a disk image, the partition starts at an offset from the beginning:

sfdisk --list stable.img
Disk stable.img: cannot get geometry

Disk stable.img: 130 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

    Device Boot Start     End   #cyls    #blocks   Id  System
stable.img1   *      0+    129     130-   1044193+  83  Linux
stable.img2          0       -       0          0    0  Empty
stable.img3          0       -       0          0    0  Empty
stable.img4          0       -       0          0    0  Empty

The 0+ in the third column tells us that the partition doesn't start exactly in the cylinder 0. That would mean it starts where the MBR is. Actually it starts in the cylinder 0 but in the second head. According to CHS reported by sfdisk, there are 63 sectors per track, so we just need to skip so many bytes: 63x512=32256. Coincidentally, 130- in the fourth column means that the partition does not reach the end of cylinder 130, which is exactly what parted was complaining above[9].

To fix the aligment we will have to do it the other way around: instead of discovering the CHS from the image size, we'll compute the image size from some desired CHS and a minimum image size. This can be done as such:

# bytes per sector
bytes=512
# sectors per track
sectors=63
# heads per track
heads=255
# bytes per cylinder is bytes*sectors*head
bpc=$(( bytes*sectors*heads ))
# number of cylinders
cylinders=$(($img_size/$bpc))
# rebound the size
img_size=$(( ($cylinders+1)*$bpc ))
qemu-img create -f raw stable.img $image_size

So we will have to somehow tell to mkfs.ext2 about the partition offset inside the disk image. We can use something that we have been using unknowingly: loopback devices. Who hasn't mounted an ISO-9660 image in the past? We used something like this:

mount -o loop debian-505-i386-CD-1.iso /mnt

This is more or less equivalent to:

losetup /dev/loop0 debian-505-i386-CD-1.iso
mount /dev/loop0 /mnt

Good thing is, we can tell losetup to simulate the start of the device some bytes inside the file. And given that everything is a file in Linux, we can even chain loop devices, such as:

losetup /dev/loop0 stable.img
losetup -o 32256 /dev/loop1 /dev/loop0

Now /dev/loop0 points to the disk image and /dev/loop1 points to the partition. There's really not much option here, so we skip to the formatting part, which is even more straightforward:

mkfs.ext2 /dev/loop1

Now to install Debian in this beast. Here we won't be exploring much either, but I will explain a couple of tricks I learned to complete this task successfully. The tool of choice is debbootstrap, which is able to install packages in a directory as if it where the root partition, so we will need to mount it first:

mount /dev/loop1 mnt

In my case I will need to install several packages besides the base install:

debootstrap --arch i386 --include=cdbs,debhelper,libsqlite3-dev,\
libssl-dev,libgstreamer-plugins-base0.10-dev,libgmp3-dev,build-essential,\
linux-image-2.6-686,grub-pc stable mnt

Notice that the base set of packages does not include nor a kernel or a boot loader, because this is normally installed by Debian Installer, so I added them to the list of packages. But this is not the only thing that the installer does (and that there is no way to repeat besides by hand): it also sets up the environment, users, apt config (from the ones used to install) and more. We will have to set those by hand.

Before running anything else, which will run under chroot, we will need to also setup some of the virtual filesystems that are running on a normal GNU/Linux setup; namely, /dev, /dev/pts and /proc. We will reuse the host's ones, using the hability to mount a dir in another:

mount -o bind /dev/ mnt/dev
mkdir mnt/dev/pts
mount -o bind /dev/pts mnt/dev/pts
mount -o bind /proc mnt/proc

Some minimal config needed includes:

# apt
echo "deb http://http.us.debian.org/debian stable         main" >  mnt/etc/apt/sources.list
echo "deb http://security.debian.org       stable/updates main" >> mnt/etc/apt/sources.list
# otherwise perl complains during installation that it can't set the locale
# actually we will have to do some little more than just this; see below
echo "en_US.UTF-8 UTF-8" > mnt/etc/locale.gen
# when installing the kernel, if this setting is not present, it thinks the
# bootloader is not able to handle initrd images[10]
echo "do_initrd = Yes" > mnt/etc/kernel-img.conf

So we use this basic config to complete even more the installation:

chroot="chroot mnt"
# compile the locales as per /etc/locale.gen
$chroot locale-gen
# download package definitions
$chroot apt-get update
# resolve virtual packages and finish the setup of packages
$chroot apt-get -f -y --force-yes install
# while we're at it, install upgrades
$chroot apt-get -y --force-yes upgrade

The last step is to install a bootloader. Here we have several options. lilo was the first Linux bootloader, which was started in 1992. Even if it can bootload almost any operating system in lots of filesystems, one of its main drawbacks is it staticness: it reads a config file, compiles the bootloader and installs it. After that you can't change anything (except for adding more boot parameters to the kernel), so if you wrote something wrong and your system does not boot, it's hard to recover. Also, if you change anything in the config file, you have to compile and install the bootloader again.

The second and third options are the two flavors of grub, the GNU GRand Unified Bootloader. The first iteration of grub, grub1 or grub-legacy how it is called now, is no longer under development or support, but a lot of people still use it for its simplicity and power. First developed in 1999, it has the hability to read the config file at boot time and it lets edit it and read the filesystems before booting. Its successor, grub2 or grub-pc, is even more modular and flexible, but takes time to relearn it.

Even with this last two options, I couldn't managed to reliably get a booting image. To be fair, I managed to do it with grub-pc, but my script had to work in a machine that boots with grub-legacy. Installing both at the same time is impossible, and I need to use the host's bootloader because I can't reliably fake the devices in a chrooted environment and using any virtual machine was imposible because the image doesn't boot yet! Talk about chicken and eggs... For the record, here's how I managed to make it work with grub-pc:

grub-install --root-directory=mnt/ --no-floppy --modules 'part_msdos ext2' /dev/loop0

So, I needed to find a bootloader that could be installed in the host machine without changing the actual bootloader in use. Luckily I talked to a friend sysadmin/guru, Ignacio Sánchez, which pointed me to extlinux, which is part of the syslinux family of bootloaders. This family also includes isolinux, famously known for booting the iso images of most of the distributions for years. I knew about the latter two, and I even used syslinux in a company I worked for two years ago in a floppy disk (!!!) used to boot the old firewall[12] and another set of diskettes for two diskless thin clients. extlinux is the youngest of the family, which is able to read and boot from extX partitions. The config file looks like a very simple lilo.conf:

default Hop
timeout 30

label Hop
    kernel /boot/vmlinuz-2.6.28-5
    append initrd=/boot/initrd.img-2.6.28-5 root=UUID=e3447f08-f8b2-4c25-93e4-76420c467384 ro

The UUID can be obtained whit this command:

blkid /dev/loop1

Installing it actually consists of two steps: first installing MBR code that boots from the partition marked as bootable[11]. The syslinux family comes with such a MBR code, so we use it:

dd if=/usr/lib/extlinux/mbr.bin of=stable.img conv=notrunc

We're almost there. Installing extlinux is really straightforward:

extlinux --heads $heads --sectors $sectors --install mnt/boot/syslinux

It only rests to umount and dismantle the loop devices in the reverse order:

umount mnt/
losetup -d /dev/loop1
losetup -d /dev/loop0

Sometimes you need to wait a couple of seconds between these commands, because they seem to be asynchronous. Otherwise you'll get errors that the device is still busy, because the previous command has finished, but the async process in the kernel has not.

The image as it is is bootable with qemu and virtualbox, but if you want to make it bootable in other, closed virtual machines, you must convert it to vmdk. qemu-utils to the rescue again:

qemu-img convert -O vmdk stable.img stable.vmdk

I have lots of things more to mention, but this post has got long enough as it is. Mostly they were references to the sites I got info from, but I know that if I try to clean it up I will procrastinate it for another month or so and probably forget about it.


[1] Currently this needs an image conversion.

[2] Of course, I strongly recommend to check the manpages of the mentioned tools.

[3] Quick, which is the actual size of the file? You can answer with powers of 2 if it makes it easier for you :)

[4] I have the tendency to write as-understandable-as-possible code; that means, I know that I'll have to read and try to understand it 6 months after I wrote it, soI try to make it as readable as possible. That includes using long options when I invoke tools in scripts and, of course, sensible class and variable names.

[5] Master Boot Record, the first sector in a disk.

[6] You will have to read sfdisk's manpage to understand what's all that.

[7] sfdisk has a neat trick: you can dump the partition table from one disk and pipe it to a sfdisk affecting another disk, actually copying the partition scheme. It comes very handy when adding disks to a raid setup.

[8] Technically we're marking it as a MSDOS type partition table.

[9] Notice that it only complains about the end bound, not the beginning bound.

[10] One interesting note: even if above I told debbootstrap to install a Linux kernel, it actually hasn't. The package linux-image-2.6-686 is a virtual one, and debbootstrap seems to not resolve this ones, but it doesn't complain either.

[11] See that Boot column in the output of sfdisk at the beginning of the post? And the * in the first and only partition? That shows it as bootable. This is an old relic from the times when operating systems relied on a dumb MBR code to boot. And now we're using exactly that to load a bootloader.

[12] Really old; we're talking about a Cyrix 486DX2 at 50MHz with 16MB de RAM, 4 NICs, all of them ISA, two of them still donning 10Base2 connectors and configurable via jumpers. We really didn't need anything bigger since the ADSL line was merely 2.5Mib/s.


References:

[A] http://pierre.palats.com/scratch/index.php?post/2008/12/15/Automatically-creating-a-disk-image-with-partition-and-bootloader


sysadmin

Posted vie 26 nov 2010 00:09:21 CET Tags: debian

Yo sabía que tener un serven en Debian Sid es una lotería, pero como no me anduvo volver a poner a andar mi instancia Xen con Debian Etch, bueno, acá estamos.

Cuestión que hoy hice una actualización de los paquetes, cosas que hago una vez por semana, y resulta que ahora mis tracs no andan. Revisando los logs de Apache veo backtraces que terminan en:

<span class="createlink">ValueError</span>: database parameter must be string or APSW Connection object

Buscando encontré que es un bug en Debian. Ahora, resulta que estoy usando apt-listbugs, que te muestra los bugs reportados de los paquetes que van a ser instalados/actualizados antes de que lo sean, de forma que puedas decidir si lo querés hacer o no. Recuerdo haber visto el bug en la lista e ignorarlo, cosa que fue mi perdición.

Según la lista trac-users, una forma de soplucionarlo es volver a la versión anterior de python-pysqlite2. ¿Y cuál era la versión anterior? Bueno, eso lo puede responder el log de la actualización, /var/log/apt/term.log:

Preparing to replace python-pysqlite2 2.3.5-1 (using .../python-pysqlite2\_2.4.0-1\_i386.deb) ...

Fantástico. Por suerte justo esa versión fué migrada a Lenny hace poco; sino, habría que haber buscado un mirror que no actualizara muy seguido. Además, parece que el bug ya está reparado por la nueva versión del paquete. Así que simplemente me bajé la 2.4.0-2 y la instalé con dpkg -i. ¡Listo!

¿Listo? I wish. El trac que estaba revisando quedó sin css y otras cosas. De los logs de Apache:

GET /~mdione/projects/kreissy/chrome/common/css/trac.css HTTP/1.1" 500

Internal Server Error. Now what? ¡Seguimos en la misma!:

<span class="createlink">ValueError</span>: database parameter must be string or APSW Connection object, referer: http://grulicueva.homelinux.net/~mdione/projects/kreissy/

Ok, tons vamos patrás. Instalo 2.3.5-1 y... ¡tampoco! Same shit... ¿No me olvido de algo? ¡Sí, de reiniciar Apache! Reinicio, y allí está mi querido trac, vivito y coleando.


PD: Ustedes tal vez se preguntarán "¿Este pibe piensa globear todo lo que le pase en Sid?". La respuesta es: espero que no. Only time will tell. Supongo que será hasta que descubra qué está bueno y qué no.

sysadmin debian

Posted mi� 27 ene 2010 23:55:55 CET Tags: debian

¡Sí señores, voy a DebConf8! MDQ, del 9 al 17.

debian

Posted mi� 27 ene 2010 23:55:55 CET Tags: debian

Since a couple of hal versions (0.5.12~git20090406.46dc48-1) in Debian Sid, it stopped using system groups as the method to grant privileges to users, and started using something called PolicyKit instead. Just to remember what are we talking about here, a user in the powerdevil group used to suspend or hibernate his machine sucessfully. But now Mr. PL is a not-understood monster and the package does not give a smooth transition. That's what I'll try to do here.

To make sure this is the problem, let's try to suspend the machine simply by calling hal through d-bus. I use qdbus here, found in the libqt4-dbus package, because it lets me introspect the dbus interface, but you could use dbus-send instead:

qdbus --system org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend 0
Error: org.freedesktop.Hal.Device.PermissionDeniedByPolicy
org.freedesktop.hal.power-management.suspend no <-- (action, result)

If we edit the file /etc/PolicyKit/PolicyKit.conf we'll see the empty default config that comes with the package. According to its documentation, we just need to add a couple of nested <match> tags with a <return> inside. The outher match will filter the hal action, the inner one the group, and the return will grant access.

... we wish! There's no way to match to a group, only to a user. Ok, the first shot will use the user, then we'll see if we really can do it.

How do we discover which action we must use? We can use polkit-action to see what are the available actions. In the first case, org.freedesktop.hal.power-management.* will do.

<match action="org.freedesktop.hal.power-management.*">
    <!--match group="powerdev"-->
    <match user="mdione">
        <return result="yes"/>
    </match>
</match>

Now the previous command suspends the machine allright! Next, removable devices:

<match action="org.freedesktop.hal.storage.mount-removable">
    <!--match group="plugdev"-->
    <match user="mdione">
        <return result="yes"/>
    </match>
</match>
<match action="org.freedesktop.hal.storage.eject">
    <!--match group="plugdev"-->
    <match user="mdione">
        <return result="yes"/>
    </match>
</match>

I added the eject action just in case. All this works fine for my user, but I really liked the group interface. The complaining about it was that it was too coarse, and now this way one can grant specific actions in amore fine grained way, but I think is too fine grained. Unluckly we cannot (ab)use the define_admin_auth tag to give a similar functionality, it doesn't work that way (I don't know what way it works either).

As a final note, see that I used a per-action approach, where the outer match points to an action. we could use a per-user approach, where the outer match points to a user:

<match user="mdione">
    <match action="...">
    <match action="...">
    <match action="...">
</match>

debian sysadmin

Posted mi� 27 ene 2010 23:55:55 CET Tags: debian

ayer le ofrecí hosting para sus proyectos a humitos. el iluso cayó rápido, sobre todo después de que probó cómo anda svn desde su casa bajando las fuentes de kreissy.

para ofrecerle este servicio le creé una cuenta en mi máquina y lo dejé hacer lo que le parezca, como ya he hecho con otra gente (por ejemplo, mi máquina es un ssh gateway paara alguna gente que se queda detrás del firewaal de la facu, pues tiene corriendo el ssh en el 443, que si está abierto).

como mi máquina es un debian sid, y éste suele sacudir los paquetes de vez en cuando (ya con el desarrollo de kreissy me mordió el cambio de SQLAlchemy, saltando de la 0.3.x a la 0.4.x, que tienen APIs sutilmente incompatibles), se me ocurrió levantar una instancia xen que ya tenía tirada por ahí. les cuento.

hace poco más de un mes nueces trajo su desktop que estaba juntando en un rincón de su pieza y, poniendo uno de los dos discos que tengo, pusimos un debian unstable, al cual convertimos en el dom0 de un xen que corrió dos instancias xen, una para él y otra para mí. la mía corría un debian etch directamente de mi disco, por las dudas en algún momento él se tuviera que llevar la máquina.

y ese momento llegó hace una semana: la vendió. me devolvió mi disco, que terminó de nuevo en mi máquina. lo monté como lo ten;ia antes y todos contentos.

entonces, hoy instalé un kernel xen. como esto es un debian sis, y no hay kernels con xen más arriba del 2.6.18, y sid ya corre 2.6.22 (para cuándo el .23?!?), tuve que bajar los paquetes linux-image-2.6.18-5-xen-686_2.6.18.dfsg.1-13_i386.deb y linux-modules-2.6.18-5-xen-686_2.6.18.dfsg.1-13_i386.deb a mano e instalarlos a mano. para instalarlos usé dpkg a lo macho, pero bien podría haber usado gdebi. configuré grub un poco a mano y reinicié.

hace mucho que uso debian, y desde hace mucho que uso kelmers compilados específicamente para mi hw (he notado que en máquinas chicas eso aumenta bastante la velocidad, así porqué no aplicar un poco la filosofía gentoo en este caso?). el tema es que estuve un rato reconfigurando algunas cosas para que anden con cómo levantó el kernel genérico algunas cosas (red y soporte de IDE en vez de PATA). sé que esas cosas se pueden arreglar con udev, pero la verdad es que siempre me llevé medio mal con él y ahora no tenía tiempo de revisarlo.

cuestión que después de un par de toqueteos levantó sin más problemas. me restregué las manos, creé el archivo de configuración de la instancia xen, y disparé un xm create. para asegurarme que estaba todo bien, con xm console luxury me ataché a la consola del domU. ésta felizmente me mostró cómo arrancó todo el sistema hasta que llegó el momento de correr /sbin/init. entonces es cuando no hizo más que imprimir:

request_module: runaway loop modprobe binfmt-464c

y nada más. buscando encontré referencias que no entendía, hasta que me cayó la ficha: la máquina de nueces era una amd64, y la instancia xen estaba en esa arquitectura. acá tengo un athlon xp 2600+, que es i386. el loco se negaba a correr soft compilado para 64 bits.

en fin. humitos empezó a subir sus cosas a su home en el dom0. ya después veré si migro eso a una máquina aparte o no. también estuvimos jugando con svk y svnadmin.

xen debian sysadmin

Posted mi� 27 ene 2010 23:55:55 CET Tags: debian

En la oficina tenemos un server que entrega nfs; también tenemos mucha gente que compila cosas. Estos dos parámetros hacen que tener sincronizadas las horas de las máquinas sea una necesidad. Pra esto se pueden usar los paquetes ntpdate (para on-time-sync) y ntp (para keep-in-sync). Hoy estuve revisando bien como interactúan ambos, sobre todo al momento del booteo. antes una descripción de qué hace cada uno.

ntp se encarga de mantener la hora de la máquina mas-o-menos sincronizada con la de una fuente externa. Si llega a haber cierta diferencia, se encarga de ir acomodando la hora de a poco, para que el sistema no sufra por cambios bruscos. Un problema que tiene es que si la diferencia con la referencia externa es muy grande, ntp no es capaz de salvar las diferencias y entonces ''no hace nada''. ntpdate se encarga simplemente de setear incondicionalmente la hora local según la hora que consiga de esta referencia externa. El escenario ideal sólo haría uso de ntp, pero en general se podría usar también ntpdate para máquinas con el reloj para-el-carajo, como parece ser el caso de al menos una de nuestra máquinas.

El tema es que, por defecto, ntpdate utiliza un archivo de configuración de ntp, pero a su vez corre despúes de éste, en cuya condición falla pues el puerto UDP que usa ya está en uso por ntp. Desinstalando ntp nos deja sin el archivo de configuración, y en realidad tiene sentido quedarnos con él.

La solución que encontré es simplemente hacer un symlink al script de ntpdate en /etc/network/if-up.d a un nombre anterior al de ntp (por ejemplo, mntpdate). Voy a ver si en debian/ubuntu me dan pelota con lo de ponerles mejor orden que simplemente el nombre.

sysadmin ubuntu debian

Posted mi� 27 ene 2010 23:55:55 CET Tags: debian