Generated.

[homepage.git] / blog / index.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:atom="http://www.w3.org/2005/Atom">
        <channel>
                <title>Petter Reinholdtsen</title>
                <description></description>
                <link>http://people.skolelinux.org/pere/blog/</link>
                <atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
        
        <item>
                <title>Togsatsing på norsk, mot sykkel</title>
                <link>http://people.skolelinux.org/pere/blog/Togsatsing_p___norsk__mot_sykkel.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Togsatsing_p___norsk__mot_sykkel.html</guid>
                <pubDate>Wed, 2 Jun 2010 23:45:00 +0200</pubDate>
                <description>
&lt;p&gt;Det står dårlig til med toget når en finner på å la det
&lt;a href=&quot;http://www.aftenposten.no/nyheter/iriks/article3677060.ece&quot;&gt;kappkjøre
med sykkel&lt;/a&gt;...  Jeg tror det trengs strukturendringer for å få
fikset på togproblemene i Norge.&lt;/p&gt;

&lt;p&gt;Mon tro hva toglinje mellom Narvik og Tromsø ville hatt slags
effekt på området der?&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>KDM fail at boot with NVidia cards - and no one try to fix it?</title>
                <link>http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</guid>
                <pubDate>Tue, 1 Jun 2010 17:05:00 +0200</pubDate>
                <description>
&lt;p&gt;It is strange to watch how a bug in Debian causing KDM to fail to
start at boot when an NVidia video card is used is handled.  The
problem seem to be that the nvidia X.org driver uses a long time to
initialize, and this duration is longer than kdm is configured to
wait.&lt;/p&gt;

&lt;p&gt;I came across two bugs related to this issue,
&lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;#583312&lt;/a&gt; initially filed
against initscripts and passed on to nvidia-glx when it became obvious
that the nvidia drivers were involved, and
&lt;a href=&quot;http://bugs.debian.org/524751&quot;&gt;#524751&lt;/a&gt; initially filed against
kdm and passed on to src:nvidia-graphics-drivers for unknown reasons.&lt;/p&gt;

&lt;p&gt;To me, it seem that no-one is interested in actually solving the
problem nvidia video card owners experience and make sure the Debian
distribution work out of the box for these users.  The nvidia driver
maintainers expect kdm to be set up to wait longer, while kdm expect
the nvidia driver maintainers to fix the driver to start faster, and
while they wait for each other I guess the users end up switching to a
distribution that work for them.  I have no idea what the solution is,
but I am pretty sure that waiting for each other is not it.&lt;/p&gt;

&lt;p&gt;I wonder why we end up handling bugs this way.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Parallellized boot seem to hold up well in Debian/testing</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</guid>
                <pubDate>Thu, 27 May 2010 23:55:00 +0200</pubDate>
                <description>
&lt;p&gt;A few days ago, parallel booting was enabled in Debian/testing.
The feature seem to hold up pretty well, but three fairly serious
issues are known and should be solved:

&lt;p&gt;&lt;ul&gt;

&lt;li&gt;The wicd package seen to
&lt;a href=&quot;http://bugs.debian.org/508289&quot;&gt;break NFS mounting&lt;/a&gt; and
&lt;a href=&quot;http://bugs.debian.org/581586&quot;&gt;network setup&lt;/a&gt; when
parallel booting is enabled.  No idea why, but the wicd maintainer
seem to be on the case.&lt;/li&gt;

&lt;li&gt;The nvidia X driver seem to
&lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;have a race condition&lt;/a&gt;
triggered more easily when parallel booting is in effect.  The
maintainer is on the case.&lt;/li&gt;

&lt;li&gt;The sysv-rc package fail to properly enable dependency based boot
sequencing (the shutdown is broken) when old file-rc users
&lt;a href=&quot;http://bugs.debian.org/575080&quot;&gt;try to switch back&lt;/a&gt; to
sysv-rc.  One way to solve it would be for file-rc to create
/etc/init.d/.legacy-bootordering, and another is to try to make
sysv-rc more robust.  Will investigate some more and probably upload a
workaround in sysv-rc to help those trying to move from file-rc to
sysv-rc get a working shutdown.&lt;/li&gt;

&lt;/ul&gt;&lt;/p&gt;

&lt;p&gt;All in all not many surprising issues, and all of them seem
solvable before Squeeze is released.  In addition to these there are
some packages with bugs in their dependencies and run level settings,
which I expect will be fixed in a reasonable time span.&lt;/p&gt;

&lt;p&gt;If you report any problems with dependencies in init.d scripts to
the BTS, please usertag the report to get it to show up at
&lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Update: Correct bug number to file-rc issue.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>More flexible firmware handling in debian-installer</title>
                <link>http://people.skolelinux.org/pere/blog/More_flexible_firmware_handling_in_debian_installer.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/More_flexible_firmware_handling_in_debian_installer.html</guid>
                <pubDate>Sat, 22 May 2010 21:30:00 +0200</pubDate>
                <description>
&lt;p&gt;After a long break from debian-installer development, I finally
found time today to return to the project.  Having to spend less time
working dependency based boot in debian, as it is almost complete now,
definitely helped freeing some time.&lt;/p&gt;

&lt;p&gt;A while back, I ran into a problem while working on Debian Edu.  We
include some firmware packages on the Debian Edu CDs, those needed to
get disk and network controllers working.  Without having these
firmware packages available during installation, it is impossible to
install Debian Edu on the given machine, and because our target group
are non-technical people, asking them to provide firmware packages on
an external medium is a support pain.  Initially, I expected it to be
enough to include the firmware packages on the CD to get
debian-installer to find and use them.  This proved to be wrong.
Next, I hoped it was enough to symlink the relevant firmware packages
to some useful location on the CD (tried /cdrom/ and
/cdrom/firmware/).  This also proved to not work, and at this point I
found time to look at the debian-installer code to figure out what was
going to work.&lt;/p&gt;

&lt;p&gt;The firmware loading code is in the hw-detect package, and a closer
look revealed that it would only look for firmware packages outside
the installation media, so the CD was never checked for firmware
packages.  It would only check USB sticks, floppies and other
&quot;external&quot; media devices.  Today I changed it to also look in the
/cdrom/firmware/ directory on the mounted CD or DVD, which should
solve the problem I ran into with Debian edu.  I also changed it to
look in /firmware/, to make sure the installer also find firmware
provided in the initrd when booting the installer via PXE, to allow us
to provide the same feature in the PXE setup included in Debian
Edu.&lt;/p&gt;

&lt;p&gt;To make sure firmware deb packages with a license questions are not
activated without asking if the license is accepted, I extended
hw-detect to look for preinst scripts in the firmware packages, and
run these before activating the firmware during installation.  The
license question is asked using debconf in the preinst, so this should
solve the issue for the firmware packages I have looked at so far.&lt;/p&gt;

&lt;p&gt;If you want to discuss the details of these features, please
contact us on debian-boot@lists.debian.org.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Magnetstripeinnhold i billetter fra Flytoget og Hurtigruten</title>
                <link>http://people.skolelinux.org/pere/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html</guid>
                <pubDate>Fri, 21 May 2010 16:00:00 +0200</pubDate>
                <description>
&lt;p&gt;For en stund tilbake kjøpte jeg en magnetkortleser for å kunne
titte på hva som er skrevet inn på magnetstripene til ulike kort.  Har
ikke hatt tid til å analysere mange kort så langt, men tenkte jeg
skulle dele innholdet på to kort med mine lesere.&lt;/p&gt;

&lt;p&gt;For noen dager siden tok jeg flyet til Harstad og Hurtigruten til
Bergen.  Flytoget fra Oslo S til flyplassen ga meg en billett med
magnetstripe.  Påtrykket finner jeg følgende informasjon:&lt;/p&gt;

&lt;pre&gt;
Flytoget Airport Express Train

Fra - Til        : Oslo Sentralstasjon
Kategori         : Voksen
Pris             : Nok 170,00
Herav mva. 8,00% : NOK 12,59
Betaling         : Kontant
Til - Fra        : Oslo Lufthavn
Utstedt:         : 08.05.10
Gyldig Fra-Til   : 08.05.10-07.11.10
Billetttype      : Enkeltbillett

102-1015-100508-48382-01-08
&lt;/pre&gt;

&lt;p&gt;På selve magnetstripen er innholdet
&lt;tt&gt;;E?+900120011=23250996541068112619257138248441708433322932704083389389062603279671261502492655?&lt;/tt&gt;.
Aner ikke hva innholdet representerer, og det er lite overlapp mellom
det jeg ser trykket på billetten og det jeg ser av tegn i
magnetstripen.  Håper det betyr at de bruker kryptografiske metoder
for å gjøre det vanskelig å forfalske billetter.&lt;/p&gt;

&lt;p&gt;Den andre billetten er fra Hurtigruten, der jeg mistenker at
strekkoden på fronten er mer brukt enn magnetstripen (det var i hvert
fall den biten vi stakk inn i dørlåsen).&lt;/p&gt;

&lt;p&gt;Påtrykket forsiden er følgende:&lt;/p&gt;

&lt;pre&gt;
Romnummer 727
Hurtigruten
Midnatsol
Reinholdtsen
Petter
Bookingno: SAX69   0742193
Harstad-Bergen
Dep: 09.05.2010 Arr: 12.05.2010
Lugar fra Risøyhamn
Kost: FRO=4
&lt;/pre&gt;

&lt;p&gt;På selve magnetstripen er innholdet
&lt;tt&gt;;1316010007421930=00000000000000000000?+E?&lt;/tt&gt;.  Heller ikke her
ser jeg mye korrespondanse mellom påtrykk og magnetstripe.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Pieces of the roaming laptop puzzle in Debian</title>
                <link>http://people.skolelinux.org/pere/blog/Pieces_of_the_roaming_laptop_puzzle_in_Debian.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Pieces_of_the_roaming_laptop_puzzle_in_Debian.html</guid>
                <pubDate>Wed, 19 May 2010 19:00:00 +0200</pubDate>
                <description>
&lt;p&gt;Today, the last piece of the puzzle for roaming laptops in Debian
Edu finally entered the Debian archive.  Today, the new
&lt;a href=&quot;http://packages.qa.debian.org/libp/libpam-mklocaluser.html&quot;&gt;libpam-mklocaluser&lt;/a&gt;
package was accepted.  Two days ago, two other pieces was accepted
into unstable.  The
&lt;a href=&quot;http://packages.qa.debian.org/p/pam-python.html&quot;&gt;pam-python&lt;/a&gt;
package needed by libpam-mklocaluser, and the
&lt;a href=&quot;http://packages.qa.debian.org/s/sssd.html&quot;&gt;sssd&lt;/a&gt; package
passed NEW on Monday.  In addition, the
&lt;a href=&quot;http://packages.qa.debian.org/libp/libpam-ccreds.html&quot;&gt;libpam-ccreds&lt;/a&gt;
package we need is in experimental (version 10-4) since Saturday, and
hopefully will be moved to unstable soon.&lt;/p&gt;

&lt;p&gt;This collection of packages allow for two different setups for
roaming laptops.  The traditional setup would be using libpam-ccreds,
nscd and libpam-mklocaluser with LDAP or Kerberos authentication,
which should work out of the box if the configuration changes proposed
for nscd in &lt;a href=&quot;http://bugs.debian.org/485282&quot;&gt;BTS report
#485282&lt;/a&gt; is implemented.  The alternative setup is to use sssd with
libpam-mklocaluser to connect to LDAP or Kerberos and let sssd take
care of the caching of passwords and group information.&lt;/p&gt;

&lt;p&gt;I have so far been unable to get sssd to work with the LDAP server
at the University, but suspect the issue is some SSL/GnuTLS related
problem with the server certificate.  I plan to update the Debian
package to version 1.2, which is scheduled for next week, and hope to
find time to make sure the next release will include both the
Debian/Ubuntu specific patches.  Upstream is friendly and responsive,
and I am sure we will find a good solution.&lt;/p&gt;

&lt;p&gt;The idea is to set up the roaming laptops to authenticate using
LDAP or Kerberos and create a local user with home directory in /home/
when a usre in LDAP logs in via KDM or GDM for the first time, and
cache the password for offline checking, as well as caching group
memberhips and other relevant LDAP information.  The
libpam-mklocaluser package was created to make sure the local home
directory is in /home/, instead of /site/server/directory/ which would
be the home directory if pam_mkhomedir was used.  To avoid confusion
with support requests and configuration, we do not want local laptops
to have users in a path that is used for the same users home directory
on the home directory servers.&lt;/p&gt;

&lt;p&gt;One annoying problem with gdm is that it do not show the PAM
message passed to the user from libpam-mklocaluser when the local user
is created.  Instead gdm simply reject the login with some generic
message.  The message is shown in kdm, ssh and login, so I guess it is
a bug in gdm.  Have not investigated if there is some other message
type that can be used instead to get gdm to also show the message.&lt;/p&gt;

&lt;p&gt;If you want to help out with implementing this for Debian Edu,
please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Parallellized boot is now the default in Debian/unstable</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html</guid>
                <pubDate>Fri, 14 May 2010 22:40:00 +0200</pubDate>
                <description>
&lt;p&gt;Since this evening, parallel booting is the default in
Debian/unstable for machines using dependency based boot sequencing.
Apparently the testing of concurrent booting has been wider than
expected, if I am to believe the
&lt;a href=&quot;http://lists.debian.org/debian-devel/2010/05/msg00122.html&quot;&gt;input
on debian-devel@&lt;/a&gt;, and I concluded a few days ago to move forward
with the feature this weekend, to give us some time to detect any
remaining problems before Squeeze is frozen.  If serious problems are
detected, it is simple to change the default back to sequential boot.
The upload of the new sysvinit package also activate a new upstream
version.&lt;/p&gt;

More information about
&lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
based boot sequencing&lt;/a&gt; is available from the Debian wiki.  It is
currently possible to disable parallel booting when one run into
problems caused by it, by adding this line to /etc/default/rcS:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
CONCURRENCY=none
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;If you report any problems with dependencies in init.d scripts to
the BTS, please usertag the report to get it to show up at
&lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Sitesummary tip: Listing MAC address of all clients</title>
                <link>http://people.skolelinux.org/pere/blog/Sitesummary_tip__Listing_MAC_address_of_all_clients.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Sitesummary_tip__Listing_MAC_address_of_all_clients.html</guid>
                <pubDate>Fri, 14 May 2010 21:10:00 +0200</pubDate>
                <description>
&lt;p&gt;In the recent Debian Edu versions, the
&lt;a href=&quot;http://wiki.debian.org/DebianEdu/HowTo/SiteSummary&quot;&gt;sitesummary
system&lt;/a&gt; is used to keep track of the machines in the school
network.  Each machine will automatically report its status to the
central server after boot and once per night.  The network setup is
also reported, and using this information it is possible to get the
MAC address of all network interfaces in the machines.  This is useful
to update the DHCP configuration.&lt;/p&gt;

&lt;p&gt;To give some idea how to use sitesummary, here is a one-liner to
ist all MAC addresses of all machines reporting to sitesummary.  Run
this on the collector host:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
perl -MSiteSummary -e &#39;for_all_hosts(sub { print join(&quot; &quot;, get_macaddresses(shift)), &quot;\n&quot;; });&#39;
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;This will list all MAC addresses assosiated with all machine, one
line per machine and with space between the MAC addresses.&lt;/p&gt;

&lt;p&gt;To allow system administrators easier job at adding static DHCP
addresses for hosts, it would be possible to extend this to fetch
machine information from sitesummary and update the DHCP and DNS
tables in LDAP using this information.  Such tool is unfortunately not
written yet.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>systemd, an interesting alternative to upstart</title>
                <link>http://people.skolelinux.org/pere/blog/systemd__an_interesting_alternative_to_upstart.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/systemd__an_interesting_alternative_to_upstart.html</guid>
                <pubDate>Thu, 13 May 2010 22:20:00 +0200</pubDate>
                <description>
&lt;p&gt;The last few days a new boot system called
&lt;a href=&quot;http://www.freedesktop.org/wiki/Software/systemd&quot;&gt;systemd&lt;/a&gt;
has been
&lt;a href=&quot;http://0pointer.de/blog/projects/systemd.html&quot;&gt;introduced&lt;/a&gt;

to the free software world.  I have not yet had time to play around
with it, but it seem to be a very interesting alternative to
&lt;a href=&quot;http://upstart.ubuntu.com/&quot;&gt;upstart&lt;/a&gt;, and might prove to be
a good alternative for Debian when we are able to switch to an event
based boot system.  Tollef is
&lt;a href=&quot;http://bugs.debian.org/580814&quot;&gt;in the process&lt;/a&gt; of getting
systemd into Debian, and I look forward to seeing how well it work.  I
like the fact that systemd handles init.d scripts with dependency
information natively, allowing them to run in parallel where upstart
at the moment do not.&lt;/p&gt;

&lt;p&gt;Unfortunately do systemd have the same problem as upstart regarding
platform support.  It only work on recent Linux kernels, and also need
some new kernel features enabled to function properly.  This means
kFreeBSD and Hurd ports of Debian will need a port or a different boot
system.  Not sure how that will be handled if systemd proves to be the
way forward.&lt;/p&gt;

&lt;p&gt;In the mean time, based on the
&lt;a href=&quot;http://lists.debian.org/debian-devel/2010/05/msg00122.html&quot;&gt;input
on debian-devel@&lt;/a&gt; regarding parallel booting in Debian, I have
decided to enable full parallel booting as the default in Debian as
soon as possible (probably this weekend or early next week), to see if
there are any remaining serious bugs in the init.d dependencies.  A
new version of the sysvinit package implementing this change is
already in experimental.  If all go well, Squeeze will be released
with parallel booting enabled by default.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Parallellizing the boot in Debian Squeeze - ready for wider testing</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html</guid>
                <pubDate>Thu, 6 May 2010 23:25:00 +0200</pubDate>
                <description>
&lt;p&gt;These days, the init.d script dependencies in Squeeze are quite
complete, so complete that it is actually possible to run all the
init.d scripts in parallell based on these dependencies.  If you want
to test your Squeeze system, make sure
&lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
based boot sequencing&lt;/a&gt; is enabled, and add this line to
/etc/default/rcS:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
CONCURRENCY=makefile
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;That is it.  It will cause sysv-rc to use the startpar tool to run
scripts in parallel using the dependency information stored in
/etc/init.d/.depend.boot, /etc/init.d/.depend.start and
/etc/init.d/.depend.stop to order the scripts.  Startpar is configured
to try to start the kdm and gdm scripts as early as possible, and will
start the facilities required by kdm or gdm as early as possible to
make this happen.&lt;/p&gt;

&lt;p&gt;Give it a try, and see if you like the result.  If some services
fail to start properly, it is most likely because they have incomplete
init.d script dependencies in their startup script (or some of their
dependent scripts have incomplete dependencies).  Report bugs and get
the package maintainers to fix it. :)&lt;/p&gt;

&lt;p&gt;Running scripts in parallel could be the default in Debian when we
manage to get the init.d script dependencies complete and correct.  I
expect we will get there in Squeeze+1, if we get manage to test and
fix the remaining issues.&lt;/p&gt;

&lt;p&gt;If you report any problems with dependencies in init.d scripts to
the BTS, please usertag the report to get it to show up at
&lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>