1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <rss version='
2.0' xmlns:lj='http://www.livejournal.org/rss/lj/
1.0/'
>
4 <title>Petter Reinholdtsen - Entries tagged sysadmin
</title>
5 <description>Entries tagged sysadmin
</description>
6 <link>http://www.hungry.com/~pere/blog/
</link>
10 <title>Some of my
2024 free software activities
</title>
11 <link>http://www.hungry.com/~pere/blog/Some_of_my_2024_free_software_activities.html
</link>
12 <guid isPermaLink=
"true">http://www.hungry.com/~pere/blog/Some_of_my_2024_free_software_activities.html
</guid>
13 <pubDate>Mon,
10 Feb
2025 09:
30:
00 +
0100</pubDate>
14 <description><p
>It is a while since I posted a summary of the free software and
15 open culture activities and projects I have worked on. Here is a
16 quick summary of the major ones from last year.
</p
>
18 <p
>I guess the biggest project of the year has been migrating orphaned
19 packages in Debian without a version control system to have a git
20 repository on salsa.debian.org. When I started in April around
450
21 the orphaned packages needed git. I
've since migrated around
250 of
22 the packages to a salsa git repository, and around
40 packages were
23 left when I took a break. Not sure who did the around
160 conversions
24 I was not involved in, but I am very glad I got some help on the
25 project. I stopped partly because some of the remaining packages
26 needed more disk space to build than I have available on my
27 development machine, and partly because some had a strange build setup
28 I could not figure out. I had a time budget of
20 minutes per
29 package, if the package proved problematic and likely to take longer,
30 I moved to another package. Might continue later, if I manage to free
31 up some disk space.
</p
>
33 <p
>Another rather big project was the translation to Norwegian Bokmål
34 and publishing of the first book ever published by a Sámi woman, the
35 «
<a href=
"http://www.hungry.com/~pere/publisher/#infoerlifellerdoed2024
">Møter
36 vi liv eller død?
</a
>» book by Elsa Laua, with a PD0 and CC-BY
37 license. I released it during the summer, and to my surprise it has
38 already sold several copies. As I suck at marketing, I did not expect
39 to sell any.
</p
>
41 <p
>A smaller, but more long term project (for more than
10 years now),
42 and related to orphaned packages in Debian, is my project to ensure a
43 simple way to install hardware related packages in Debian when the
44 relevant hardware is present in a machine. It made a fairly big
45 advance forward last year, partly because I have been poking and
46 begging package maintainers and upstream developers to include
47 AppStream metadata XML in their packages. I
've also released a few
48 new versions of the isenkram system with some robustness improvements.
49 Today
127 packages in Debian provide such information, allowing
50 <tt
>isenkram-lookup
</tt
> to propose them. Will keep pushing until the
51 around
35 package names currently hard coded in the isenkram package
52 are down to zero, so only information provided by individual packages
53 are used for this feature.
</p
>
55 <p
>As part of the work on AppStream, I have sponsored several packages
56 into Debian where the maintainer wanted to fix the issue but lacked
57 direct upload rights. I
've also sponsored a few other packages, when
58 approached by the maintainer.
</p
>
60 <p
>I would also like to mention two hardware related packages in
61 particular where I have been involved, the megactl and mfi-util
62 packages. Both work with the hardware RAID systems in several Dell
63 PowerEdge servers, and the first one is already available in Debian
64 (and of course, proposed by isenkram when used on the appropriate Dell
65 server), the other is waiting for NEW processing since this autumn. I
66 manage several such Dell servers and would like the tools needed to
67 monitor and configure these RAID controllers to be available from
68 within Debian out of the box.
</p
>
70 <p
>Vaguely related to hardware support in Debian, I have also been
71 trying to find ways to help out the Debian ROCm team, to improve the
72 support in Debian for my artificial idiocy (AI) compute node. So far
73 only uploaded one package, helped test the initial packaging of
74 llama.cpp and tried to figure out how to get good speech recognition
75 like Whisper into Debian.
<p
>
77 <p
>I am still involved in the LinuxCNC project, and organised a
78 developer gathering in Norway last summer. A new one is planned the
79 summer of
2025. I
've also helped evaluate patches and uploaded new
80 versions of LinuxCNC into Debian.
</p
>
82 <p
>After a
10 years long break, we managed to get a new and improved
83 upstream version of
<tt
>lsdvd
</tt
> released just before Christmas. As
84 I use it regularly to maintain my DVD archive, I was very happy to
85 finally get out a version supporting DVDDiscID useful for uniquely
86 identifying DVDs. I am dreaming of a Internet service mapping DVD IDs
87 to IMDB movie IDs, to make life as a DVD collector easier.
</p
>
89 <p
>My involvement in Norwegian archive standardisation and the free
90 software implementation of the vendor neutral Noark
5 API continued
91 for the entire year. I
've been pushing patches into both the API and
92 the test code for the API, participated in several editorial meetings
93 regarding the Noark
5 Tjenestegrensesnitt specification, submitted
94 several proposals for improvements for the same. We also organised a
95 small seminar for Noark
5 interested people, and is organising a new
96 seminar in a month.
</p
>
98 <p
>Part of the year was spent working on and coordinating a Norwegian
99 Bokmål translation of the marvellous children
's book
100 «
<a href=
"https://fsfe.org/activities/ada-zangemann/
">Ada and
101 Zangemann
<a
>», which focus on the right to repair and control your own
102 property, and the value of controlling the software on the devices you
103 own. The translation is mostly complete, and is now waiting for a
104 transformation of the project and manuscript to use Docbook XML
105 instead of a home made semi-text based format. Great progress is
106 being made and the new book build process is almost complete.
</p
>
108 <p
>I have also been looking at how to companies in Norway can use free
109 software to report their accounting summaries to the Norwegian
110 government. Several new regulations make it very hard for companies
111 to do use free software for accounting, and I would like to change
112 this. Found a few drafts for opening up the reporting process, and
113 have read up on some of the specifications, but nothing much is
114 working yet.
</p
>
116 <p
>These were just the top of the iceberg, but I guess this blog post
117 is long enough now. If you would like to help with any of these
118 projects, please get in touch, either directly on the project mailing
119 lists and forums, or with me via email, IRC or Signal. :)
</p
>
121 <p
>As usual, if you use Bitcoin and want to show your support of my
122 activities, please send Bitcoin donations to my address
123 <b
><a href=
"bitcoin:
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
</a
></b
>.
</p
>
128 <title>Secure Socket API - a simple and powerful approach for TLS support in software
</title>
129 <link>http://www.hungry.com/~pere/blog/Secure_Socket_API___a_simple_and_powerful_approach_for_TLS_support_in_software.html
</link>
130 <guid isPermaLink=
"true">http://www.hungry.com/~pere/blog/Secure_Socket_API___a_simple_and_powerful_approach_for_TLS_support_in_software.html
</guid>
131 <pubDate>Sat,
6 Jun
2020 12:
40:
00 +
0200</pubDate>
132 <description><p
>As a member of the
<a href=
"https://www.nuug.no/
">Norwegian Unix
133 User Group
</a
>, I have the pleasure of receiving the
134 <a href=
"https://www.usenix.org/
">USENIX
</a
> magazine
135 <a href=
"https://www.usenix.org/publications/login/
">;login:
</a
>
136 several times a year. I rarely have time to read all the articles,
137 but try to at least skim through them all as there is a lot of nice
138 knowledge passed on there. I even carry the latest issue with me most
139 of the time to try to get through all the articles when I have a few
140 spare minutes.
</p
>
142 <p
>The other day I came across a nice article titled
143 "<a href=
"https://www.usenix.org/publications/login/winter2018/oneill
">The
144 Secure Socket API: TLS as an Operating System Service
</a
>" with a
145 marvellous idea I hope can make it all the way into the POSIX standard.
146 The idea is as simple as it is powerful. By introducing a new
147 socket() option IPPROTO_TLS to use TLS, and a system wide service to
148 handle setting up TLS connections, one both make it trivial to add TLS
149 support to any program currently using the POSIX socket API, and gain
150 system wide control over certificates, TLS versions and encryption
151 systems used. Instead of doing this:
</p
>
153 <p
><blockquote
><pre
>
154 int socket = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
155 </pre
></blockquote
></p
>
157 <p
>the program code would be doing this:
<p
>
159 <p
><blockquote
><pre
>
160 int socket = socket(PF_INET, SOCK_STREAM, IPPROTO_TLS);
161 </pre
></blockquote
></p
>
163 <p
>According to the ;login: article, converting a C program to use TLS
164 would normally modify only
5-
10 lines in the code, which is amazing
165 when compared to using for example the OpenSSL API.
</p
>
167 <p
>The project has set up the
168 <a href=
"https://securesocketapi.org/
">https://securesocketapi.org/
</a
>
169 web site to spread the idea, and the code for a kernel module and the
170 associated system daemon is available from two github repositories:
171 <a href=
"https://github.com/markoneill/ssa
">ssa
</a
> and
172 <a href=
"https://github.com/markoneill/ssa-daemon
">ssa-daemon
</a
>.
173 Unfortunately there is no explicit license information with the code,
174 so its copyright status is unclear. A
175 <a href=
"https://github.com/markoneill/ssa/issues/
2">request to solve
176 this
</a
> about it has been unsolved since
2018-
08-
17.
</p
>
178 <p
>I love the idea of extending socket() to gain TLS support, and
179 understand why it is an advantage to implement this as a kernel module
180 and system wide service daemon, but can not help to think that it
181 would be a lot easier to get projects to move to this way of setting
182 up TLS if it was done with a user space approach where programs
183 wanting to use this API approach could just link with a wrapper
186 <p
>I recommend you check out this simple and powerful approach to more
187 secure network connections. :)
</p
>
189 <p
>As usual, if you use Bitcoin and want to show your support of my
190 activities, please send Bitcoin donations to my address
191 <b
><a href=
"bitcoin:
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
</a
></b
>.
</p
>
196 <title>Some notes on fault tolerant storage systems
</title>
197 <link>http://www.hungry.com/~pere/blog/Some_notes_on_fault_tolerant_storage_systems.html
</link>
198 <guid isPermaLink=
"true">http://www.hungry.com/~pere/blog/Some_notes_on_fault_tolerant_storage_systems.html
</guid>
199 <pubDate>Wed,
1 Nov
2017 15:
35:
00 +
0100</pubDate>
200 <description><p
>If you care about how fault tolerant your storage is, you might
201 find these articles and papers interesting. They have formed how I
202 think of when designing a storage system.
</p
>
206 <li
>USENIX :login;
<a
207 href=
"https://www.usenix.org/publications/login/summer2017/ganesan
">Redundancy
208 Does Not Imply Fault Tolerance. Analysis of Distributed Storage
209 Reactions to Single Errors and Corruptions
</a
> by Aishwarya Ganesan,
210 Ramnatthan Alagappan, Andrea C. Arpaci-Dusseau, and Remzi
211 H. Arpaci-Dusseau
</li
>
214 <a href=
"http://www.zdnet.com/article/why-raid-
5-stops-working-in-
2009/
">Why
215 RAID
5 stops working in
2009</a
> by Robin Harris
</li
>
218 <a href=
"http://www.zdnet.com/article/why-raid-
6-stops-working-in-
2019/
">Why
219 RAID
6 stops working in
2019</a
> by Robin Harris
</li
>
221 <li
>USENIX FAST
'07
222 <a href=
"http://research.google.com/archive/disk_failures.pdf
">Failure
223 Trends in a Large Disk Drive Population
</a
> by Eduardo Pinheiro,
224 Wolf-Dietrich Weber and Luiz André Barroso
</li
>
226 <li
>USENIX ;login:
<a
227 href=
"https://www.usenix.org/system/files/login/articles/hughes12-
04.pdf
">Data
228 Integrity. Finding Truth in a World of Guesses and Lies
</a
> by Doug
231 <li
>USENIX FAST
'08
232 <a href=
"https://www.usenix.org/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/
">An
233 Analysis of Data Corruption in the Storage Stack
</a
> by
234 L. N. Bairavasundaram, G. R. Goodson, B. Schroeder, A. C.
235 Arpaci-Dusseau, and R. H. Arpaci-Dusseau
</li
>
237 <li
>USENIX FAST
'07 <a
238 href=
"https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder_html/
">Disk
239 failures in the real world: what does an MTTF of
1,
000,
000 hours mean
240 to you?
</a
> by B. Schroeder and G. A. Gibson.
</li
>
242 <li
>USENIX ;login:
<a
243 href=
"https://www.usenix.org/events/fast08/tech/full_papers/jiang/jiang_html/
">Are
244 Disks the Dominant Contributor for Storage Failures? A Comprehensive
245 Study of Storage Subsystem Failure Characteristics
</a
> by Weihang
246 Jiang, Chongfeng Hu, Yuanyuan Zhou, and Arkady Kanevsky
</li
>
248 <li
>SIGMETRICS
2007
249 <a href=
"http://research.cs.wisc.edu/adsl/Publications/latent-sigmetrics07.pdf
">An
250 analysis of latent sector errors in disk drives
</a
> by
251 L. N. Bairavasundaram, G. R. Goodson, S. Pasupathy, and J. Schindler
</li
>
255 <p
>Several of these research papers are based on data collected from
256 hundred thousands or millions of disk, and their findings are eye
257 opening. The short story is simply do not implicitly trust RAID or
258 redundant storage systems. Details matter. And unfortunately there
259 are few options on Linux addressing all the identified issues. Both
260 ZFS and Btrfs are doing a fairly good job, but have legal and
261 practical issues on their own. I wonder how cluster file systems like
262 Ceph do in this regard. After all, there is an old saying, you know
263 you have a distributed system when the crash of a computer you have
264 never heard of stops you from getting any work done. The same holds
265 true if fault tolerance do not work.
</p
>
267 <p
>Just remember, in the end, it do not matter how redundant, or how
268 fault tolerant your storage is, if you do not continuously monitor its
269 status to detect and replace failed disks.
</p
>
271 <p
>As usual, if you use Bitcoin and want to show your support of my
272 activities, please send Bitcoin donations to my address
273 <b
><a href=
"bitcoin:
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
</a
></b
>.
</p
>
278 <title>Detecting NFS hangs on Linux without hanging yourself...
</title>
279 <link>http://www.hungry.com/~pere/blog/Detecting_NFS_hangs_on_Linux_without_hanging_yourself___.html
</link>
280 <guid isPermaLink=
"true">http://www.hungry.com/~pere/blog/Detecting_NFS_hangs_on_Linux_without_hanging_yourself___.html
</guid>
281 <pubDate>Thu,
9 Mar
2017 15:
20:
00 +
0100</pubDate>
282 <description><p
>Over the years, administrating thousand of NFS mounting linux
283 computers at the time, I often needed a way to detect if the machine
284 was experiencing NFS hang. If you try to use
<tt
>df
</tt
> or look at a
285 file or directory affected by the hang, the process (and possibly the
286 shell) will hang too. So you want to be able to detect this without
287 risking the detection process getting stuck too. It has not been
288 obvious how to do this. When the hang has lasted a while, it is
289 possible to find messages like these in dmesg:
</p
>
291 <p
><blockquote
>
292 nfs: server nfsserver not responding, still trying
293 <br
>nfs: server nfsserver OK
294 </blockquote
></p
>
296 <p
>It is hard to know if the hang is still going on, and it is hard to
297 be sure looking in dmesg is going to work. If there are lots of other
298 messages in dmesg the lines might have rotated out of site before they
299 are noticed.
</p
>
301 <p
>While reading through the nfs client implementation in linux kernel
302 code, I came across some statistics that seem to give a way to detect
303 it. The om_timeouts sunrpc value in the kernel will increase every
304 time the above log entry is inserted into dmesg. And after digging a
305 bit further, I discovered that this value show up in
306 /proc/self/mountstats on Linux.
</p
>
308 <p
>The mountstats content seem to be shared between files using the
309 same file system context, so it is enough to check one of the
310 mountstats files to get the state of the mount point for the machine.
311 I assume this will not show lazy umounted NFS points, nor NFS mount
312 points in a different process context (ie with a different filesystem
313 view), but that does not worry me.
</p
>
315 <p
>The content for a NFS mount point look similar to this:
</p
>
317 <p
><blockquote
><pre
>
319 device /dev/mapper/Debian-var mounted on /var with fstype ext3
320 device nfsserver:/mnt/nfsserver/home0 mounted on /mnt/nfsserver/home0 with fstype nfs statvers=
1.1
321 opts: rw,vers=
3,rsize=
65536,wsize=
65536,namlen=
255,acregmin=
3,acregmax=
60,acdirmin=
30,acdirmax=
60,soft,nolock,proto=tcp,timeo=
600,retrans=
2,sec=sys,mountaddr=
129.240.3.145,mountvers=
3,mountport=
4048,mountproto=udp,local_lock=all
323 caps: caps=
0x3fe7,wtmult=
4096,dtsize=
8192,bsize=
0,namlen=
255
324 sec: flavor=
1,pseudoflavor=
1
325 events:
61063112 732346265 1028140 35486205 16220064 8162542 761447191 71714012 37189 3891185 45561809 110486139 4850138 420353 15449177 296502 52736725 13523379 0 52182 9016896 1231 0 0 0 0 0
326 bytes:
166253035039 219519120027 0 0 40783504807 185466229638 11677877 45561809
327 RPC iostats version:
1.0 p/v:
100003/
3 (nfs)
328 xprt: tcp
925 1 6810 0 0 111505412 111480497 109 2672418560317 0 248 53869103 22481820
330 NULL:
0 0 0 0 0 0 0 0
331 GETATTR:
61063106 61063108 0 9621383060 6839064400 453650 77291321 78926132
332 SETATTR:
463469 463470 0 92005440 66739536 63787 603235 687943
333 LOOKUP:
17021657 17021657 0 3354097764 4013442928 57216 35125459 35566511
334 ACCESS:
14281703 14290009 5 2318400592 1713803640 1709282 4865144 7130140
335 READLINK:
125 125 0 20472 18620 0 1112 1118
336 READ:
4214236 4214237 0 715608524 41328653212 89884 22622768 22806693
337 WRITE:
8479010 8494376 22 187695798568 1356087148 178264904 51506907 231671771
338 CREATE:
171708 171708 0 38084748 46702272 873 1041833 1050398
339 MKDIR:
3680 3680 0 773980 993920 26 23990 24245
340 SYMLINK:
903 903 0 233428 245488 6 5865 5917
341 MKNOD:
80 80 0 20148 21760 0 299 304
342 REMOVE:
429921 429921 0 79796004 61908192 3313 2710416 2741636
343 RMDIR:
3367 3367 0 645112 484848 22 5782 6002
344 RENAME:
466201 466201 0 130026184 121212260 7075 5935207 5961288
345 LINK:
289155 289155 0 72775556 67083960 2199 2565060 2585579
346 READDIR:
2933237 2933237 0 516506204 13973833412 10385 3190199 3297917
347 READDIRPLUS:
1652839 1652839 0 298640972 6895997744 84735 14307895 14448937
348 FSSTAT:
6144 6144 0 1010516 1032192 51 9654 10022
349 FSINFO:
2 2 0 232 328 0 1 1
350 PATHCONF:
1 1 0 116 140 0 0 0
351 COMMIT:
0 0 0 0 0 0 0 0
353 device binfmt_misc mounted on /proc/sys/fs/binfmt_misc with fstype binfmt_misc
355 </pre
></blockquote
></p
>
357 <p
>The key number to look at is the third number in the per-op list.
358 It is the number of NFS timeouts experiences per file system
359 operation. Here
22 write timeouts and
5 access timeouts. If these
360 numbers are increasing, I believe the machine is experiencing NFS
361 hang. Unfortunately the timeout value do not start to increase right
362 away. The NFS operations need to time out first, and this can take a
363 while. The exact timeout value depend on the setup. For example the
364 defaults for TCP and UDP mount points are quite different, and the
365 timeout value is affected by the soft, hard, timeo and retrans NFS
366 mount options.
</p
>
368 <p
>The only way I have been able to get working on Debian and RedHat
369 Enterprise Linux for getting the timeout count is to peek in /proc/.
371 <ahref=
"http://docs.oracle.com/cd/E19253-
01/
816-
4555/netmonitor-
12/index.html
">Solaris
372 10 System Administration Guide: Network Services
</a
>, the
'nfsstat -c
'
373 command can be used to get these timeout values. But this do not work
374 on Linux, as far as I can tell. I
375 <ahref=
"http://bugs.debian.org/
857043">asked Debian about this
</a
>,
376 but have not seen any replies yet.
</p
>
378 <p
>Is there a better way to figure out if a Linux NFS client is
379 experiencing NFS hangs? Is there a way to detect which processes are
380 affected? Is there a way to get the NFS mount going quickly once the
381 network problem causing the NFS hang has been cleared? I would very
382 much welcome some clues, as we regularly run into NFS hangs.
</p
>
387 <title>Debian Jessie, PXE and automatic firmware installation
</title>
388 <link>http://www.hungry.com/~pere/blog/Debian_Jessie__PXE_and_automatic_firmware_installation.html
</link>
389 <guid isPermaLink=
"true">http://www.hungry.com/~pere/blog/Debian_Jessie__PXE_and_automatic_firmware_installation.html
</guid>
390 <pubDate>Fri,
17 Oct
2014 14:
10:
00 +
0200</pubDate>
391 <description><p
>When PXE installing laptops with Debian, I often run into the
392 problem that the WiFi card require some firmware to work properly.
393 And it has been a pain to fix this using preseeding in Debian.
394 Normally something more is needed. But thanks to
395 <a href=
"https://packages.qa.debian.org/i/isenkram.html
">my isenkram
396 package
</a
> and its recent tasksel extension, it has now become easy
397 to do this using simple preseeding.
</p
>
399 <p
>The isenkram-cli package provide tasksel tasks which will install
400 firmware for the hardware found in the machine (actually, requested by
401 the kernel modules for the hardware). (It can also install user space
402 programs supporting the hardware detected, but that is not the focus
403 of this story.)
</p
>
405 <p
>To get this working in the default installation, two preeseding
406 values are needed. First, the isenkram-cli package must be installed
407 into the target chroot (aka the hard drive) before tasksel is executed
408 in the pkgsel step of the debian-installer system. This is done by
409 preseeding the base-installer/includes debconf value to include the
410 isenkram-cli package. The package name is next passed to debootstrap
411 for installation. With the isenkram-cli package in place, tasksel
412 will automatically use the isenkram tasks to detect hardware specific
413 packages for the machine being installed and install them, because
414 isenkram-cli contain tasksel tasks.
</p
>
416 <p
>Second, one need to enable the non-free APT repository, because
417 most firmware unfortunately is non-free. This is done by preseeding
418 the apt-mirror-setup step. This is unfortunate, but for a lot of
419 hardware it is the only option in Debian.
</p
>
421 <p
>The end result is two lines needed in your preseeding file to get
422 firmware installed automatically by the installer:
</p
>
424 <p
><blockquote
><pre
>
425 base-installer base-installer/includes string isenkram-cli
426 apt-mirror-setup apt-setup/non-free boolean true
427 </pre
></blockquote
></p
>
429 <p
>The current version of isenkram-cli in testing/jessie will install
430 both firmware and user space packages when using this method. It also
431 do not work well, so use version
0.15 or later. Installing both
432 firmware and user space packages might give you a bit more than you
433 want, so I decided to split the tasksel task in two, one for firmware
434 and one for user space programs. The firmware task is enabled by
435 default, while the one for user space programs is not. This split is
436 implemented in the package currently in unstable.
</p
>
438 <p
>If you decide to give this a go, please let me know (via email) how
439 this recipe work for you. :)
</p
>
441 <p
>So, I bet you are wondering, how can this work. First and
442 foremost, it work because tasksel is modular, and driven by whatever
443 files it find in /usr/lib/tasksel/ and /usr/share/tasksel/. So the
444 isenkram-cli package place two files for tasksel to find. First there
445 is the task description file (/usr/share/tasksel/descs/isenkram.desc):
</p
>
447 <p
><blockquote
><pre
>
448 Task: isenkram-packages
450 Description: Hardware specific packages (autodetected by isenkram)
451 Based on the detected hardware various hardware specific packages are
453 Test-new-install: show show
455 Packages: for-current-hardware
457 Task: isenkram-firmware
459 Description: Hardware specific firmware packages (autodetected by isenkram)
460 Based on the detected hardware various hardware specific firmware
461 packages are proposed.
462 Test-new-install: mark show
464 Packages: for-current-hardware-firmware
465 </pre
></blockquote
></p
>
467 <p
>The key parts are Test-new-install which indicate how the task
468 should be handled and the Packages line referencing to a script in
469 /usr/lib/tasksel/packages/. The scripts use other scripts to get a
470 list of packages to install. The for-current-hardware-firmware script
471 look like this to list relevant firmware for the machine:
473 <p
><blockquote
><pre
>
478 isenkram-autoinstall-firmware -l
479 </pre
></blockquote
></p
>
481 <p
>With those two pieces in place, the firmware is installed by
482 tasksel during the normal d-i run. :)
</p
>
484 <p
>If you want to test what tasksel will install when isenkram-cli is
485 installed, run
<tt
>DEBIAN_PRIORITY=critical tasksel --test
486 --new-install
</tt
> to get the list of packages that tasksel would
489 <p
><a href=
"https://wiki.debian.org/DebianEdu/
">Debian Edu
</a
> will be
490 pilots in testing this feature, as isenkram is used there now to
491 install firmware, replacing the earlier scripts.
</p
>
496 <title>Scripting the Cerebrum/bofhd user administration system using XML-RPC
</title>
497 <link>http://www.hungry.com/~pere/blog/Scripting_the_Cerebrum_bofhd_user_administration_system_using_XML_RPC.html
</link>
498 <guid isPermaLink=
"true">http://www.hungry.com/~pere/blog/Scripting_the_Cerebrum_bofhd_user_administration_system_using_XML_RPC.html
</guid>
499 <pubDate>Thu,
6 Dec
2012 10:
30:
00 +
0100</pubDate>
500 <description><p
>Where I work at the
<a href=
"http://www.uio.no/
">University of
501 Oslo
</a
>, we use the
502 <a href=
"http://sourceforge.net/projects/cerebrum/
">Cerebrum user
503 administration system
</a
> to maintain users, groups, DNS, DHCP, etc.
504 I
've known since the system was written that the server is providing
505 an
<a href=
"http://en.wikipedia.org/wiki/XML-RPC
">XML-RPC
</a
> API, but
506 I have never spent time to try to figure out how to use it, as we
507 always use the bofh command line client at work. Until today. I want
508 to script the updating of DNS and DHCP to make it easier to set up
509 virtual machines. Here are a few notes on how to use it with
512 <p
>I started by looking at the source of the Java
513 <a href=
"http://cerebrum.svn.sourceforge.net/viewvc/cerebrum/trunk/cerebrum/clients/jbofh/
">bofh
514 client
</a
>, to figure out how it connected to the API server. I also
515 googled for python examples on how to use XML-RPC, and found
516 <a href=
"http://tldp.org/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-python.html
">a
517 simple example in
</a
> the XML-RPC howto.
</p
>
519 <p
>This simple example code show how to connect, get the list of
520 commands (as a JSON dump), and how to get the information about the
521 user currently logged in:
</p
>
523 <blockquote
><pre
>
524 #!/usr/bin/env python
527 server_url =
'https://cerebrum-uio.uio.no:
8000';
528 username = getpass.getuser()
529 password = getpass.getpass()
530 server = xmlrpclib.Server(server_url);
531 #print server.get_commands(sessionid)
532 sessionid = server.login(username, password)
533 print server.run_command(sessionid,
"user_info
", username)
534 result = server.logout(sessionid)
536 </pre
></blockquote
>
538 <p
>Armed with this knowledge I can now move forward and script the DNS
539 and DHCP updates I wanted to do.
</p
>
projects / homepage.git / blob