mikas blog

Wie man eine Frage zur Konfiguration des Regionalcodes nicht stellen sollte:

86 Wörter

Du schreibst 504 Zeichen pro Minute
Du hast 86 korrekt geschriebene Wörter und
Du hast 0 falsch geschriebene Wörter

via Jens

Die Grazer LinuxTage (GLT08) finden auch heuer wieder im Rahmen der Linuxwochen Österreich statt – und zwar am Samstag, den 19. April 2008 auf der FH Joanneum. Weitere Informationen zu GLT08 auf linuxtage.at

Wir (das Organisations-Team der GLT08) sind auf der Suche nach Vortragenden! Es gibt kein spezielles Thema, sondern die Einteilung in die Themengebiete:

• Desktop/Anwender
• Entwickler
• Manager
• Administratoren

Wir suchen nicht nur Experten zu Spezialthemen, sondern auch Leute, die Einsteiger-Vorträge halten möchten!

Du möchtest einen Vortrag oder Workshop auf den GLT08 halten? Dann reiche diesen bitte ein!

Wir suchen übrigens auch noch motivierte Helfer, die im Vorfeld und/oder vor Ort anpacken können. Wer motiviert ist möge sich doch bitte einfach per Mail an graz08 (at) linuxtage.at bei uns melden. Danke!

Derzeit laufen gerade System-Updates oder Sicherungen.
Von Montag bis Sonntag wird die Datenbank täglich gesichert und ist deshalb von 02:30 – 02:40 offline.
Außerdem gibt es komplettes Backup am Mittwoch und Samstag, dabei ist die Datenbank von 2:30 – 3:20 nicht erreichbar.

Bitte versuchen Sie es später nochmals und benutzen Sie einstweilen
einen anderen Online-Katalog des Österreichischen Bibliothekenverbundes.

Entladung.net ist ein Video-Podcast über Elektronik. Wir wollen unser Publikum bei den absoluten Grundlagen abholen und schrittweise in die Welt der Elektronik begleiten. Dabei ist es uns ein Anliegen nicht nur “Kochrezepte” zu liefern sondern auch detailiert zu erklären wie die Dinge funktionieren.

— entladung.net

mika@grmlvrs ~www/grml % hg ci -m 'Finalize grml 1.1-rc1, grml64 0.2-rc1 + grml[64]-medium 0.1-rc1'
summary:     Finalize grml 1.1-rc1, grml64 0.2-rc1 + grml[64]-medium 0.1-rc1
mika @ Fre Dez 28 23:02:26 CET 2007
mika@grmlvrs ~www/grml % hg tag grml_1.1-rc1
summary:     Added tag grml_1.1-rc1 for changeset 8506fc040e39d96b4b1657b15bb8ccdfa4be5a5c
mika @ Fre Dez 28 23:02:37 CET 2007
mika@grmlvrs ~www/grml %

Done that… auch die Webseite passt jetzt für die neuen Release-Kandidaten von grml, die da wären:

• grml 1.1-rc1 – Codename Skunk
• grml64 0.2-rc1 – Codename Schwammerlklauber
• grml-medium 0.1-rc1 und grml64-medium 0.1-rc1 – Codename Pfuh

Einige Monate Entwicklung, ein neues Build-Framework names grml-live und der aufmerksame Leser und grml-Kenner wird in obiger Liste auch einen neuen grml-Flavour ausmachen: grml-medium soll die Lücke zwischen grml-small und dem großen Bruder schließen.

Ich halte es kurz: runterladen, anwerfen und was man so typischerweise braucht testen. Falls jemand noch einen Bug finden sollte: bitte melden, damit wir das nach Möglichkeit noch für die bald erscheinende stabile Release richten können.

Ein großes Danke an dieser Stelle noch an alle aktiven grml-Entwickler und die fleißigen Contributor!

Happy hacking!

Update on 2024-11-22: update URL for .zshrc.local (replace http://git.grml.org/f/grml-etc-core/etc/skel/.zshrc with grml.org/console/zshrc.local) and replace http://git.grml.org/?p=grml-etc-core.git with github.com/grml/grml-etc-core

Update on 2024-02-16: provide curl usage instructions.

Update on 2020-12-04: include tmux.conf.

Update on 2017-01-27: provide easy to remember grml.org/console/$filename URLs.

Update on 2009-02-13: adjust zshrc setup as .zshrc.global is deprecated, see grml-zsh-refcard.

Update on 2008-10-10: replace old hg.grml.org URLs with current git.grml.org.

Update on 2009-08-11: refer to /etc/vim/vimrc as /etc/vim/vimrc and /etc/skel/.vimrc have been merged

You like grml‘s Zsh, GNU screen and Vim configuration? No problem to get that on non-grml/non-Debian/non-Linux/… systems as well. Just copy/paste the following lines which are stolen from one of my personal cheatsheets for working on foreign systems (being Linux as well as Solaris, BSD, Windows,…):

# IMPORTANT: please note that you might override existing
# configuration files in the current working directory! => 
wget -O .screenrc   https://grml.org/console/screenrc
wget -O .tmux.conf  https://grml.org/console/tmux.conf
wget -O .vimrc      https://grml.org/console/vimrc
wget -O .zshrc      https://grml.org/console/zshrc
# optional:
# wget -O .zshrc.local https://grml.org/console/zshrc.local

Or if you prefer curl instead:

# IMPORTANT: please note that you might override existing
# configuration files in the current working directory! => 
curl -L -o .screenrc   https://grml.org/console/screenrc
curl -L -o .tmux.conf  https://grml.org/console/tmux.conf
curl -L -o .vimrc      https://grml.org/console/vimrc
curl -L -o .zshrc      https://grml.org/console/zshrc
# optional:
# wget -O .zshrc.local https://grml.org/console/zshrc.local

If you do not want to copy/paste just use the grml-config.sh script instead.

Notice: the above URLs always points to the most recent version of the file(s), so it’s easy to stay up2date as well as checking out a very specific version of the configuration files. Just look at github.com/grml/grml-etc-core.

Disclaimer: If you notice any problems with the configuration files on your system/platform please let us know, it’s considered a bug then. Any other feedback is welcome as well of course. :)

Ort:
ESC/Labor, Jakoministraße 16, 8010 Graz

Termine:
Mittwoch, 19 Dezember 2007 16:00 – 18:00 Uhr
Hands On Registered Commons Workshop mit Roland Alton-Scheidl. Anmeldung an sicherimnetz@mur.at erforderlich.

Mittwoch, 19 Dezember 2007 19:00 Uhr
Creative Commons und Registered Commons Vortrag von Roland Alton-Scheidl

Weitere Details bei mur.at.

When cloning a Linux/Debian system 1:1 you should have a checklist of what’s important to change on the cloned system.

For cloning I use the grml Linux Live-CD of course (the following tips are part of grml-tips as well). To create a 1:1 clone I boot grml on the systems (usually using the ssh=password bootoption to be able to access the system remotely as well) and use something like:

Listener:
# nc -vlp 30000 > /dev/sda1
Source:
# dd if=/dev/sda1 bs=$VALUE | nc -vq 0 $IP_OF_LISTENER 30000

When I have to leave the place where the clone process is running and if the CD-ROM doesn’t reinsert CDs on reboot automatically (usually that’s the case for server systems) I can use my remote-reboot procedure via ssh later on like:

eject &>/dev/null
umount -l /cdrom
eject /dev/cdrom
echo b > /proc/sysrq-trigger

But stop: before executing the last steps to reboot the server you should take care of a few important steps, otherwise rebooting might fail and you won’t be able to login via SSH. ;-) That’s my personal checklist:

• Using LVM? If you want to rename any devices using vgrename/lvrename do not forget to adjust entries in /etc/fstab, lilo/grub,…
• Check that labels/UUID/… for stable devices inside your configuration path (bootloader config, /etc/fstab, /etc/udev/*,…) match with the present setup (of course that’s especially important if you change any labels/UUIDs/… on your box after cloning)
• Using udev, right? Do not forget to adjust any statically configured network interfaces as well – check out /etc/udev/rules.d/z25_persistent-net.rules and /lib/udev/write_net_rules (that’s probably the most common and serious pitfall when cloning systems BTW)
• Make sure to configure your network setup accordingly (using /etc/network/interfaces)
• Do you use any kernel modules on one host you don’t want to use on the other one? Check blacklisting, configuration,… in /etc/modprobe.d/ and /etc/modules.
• And last but not least: if you change any of the "core files" (see above bullets to get an idea what I’m talking about) make sure to rebuild your initrd (executing ‘update-initramfs -c -t -k $KERNEL_VERSION’), and when using lilo don’t forget to execute lilo as well :-)

Tip: I highly recommend the use of a version controll system for maintaining /etc, for example etckeeper and mercurial should do the job for you.

Ab 17.12. heisst es Schlange stehen, denn dann gibt es das c’t special 02/2008 Magazin zum Thema Netzwerke im Handel. Und weil grml Teil der beliegenden DVD ist, heisst es: kaufen! :)

The battery of your laptop keeps getting drained even though you are using Suspend-To-Disk [STD]? (No, I’m not talking about Suspend-To-RAM!) That’s what happens at least on my Lenovo ThinkPad X61s notebook. Thankfully there exists a workaround:

Check out what suspend method you use:

# cat /sys/power/disk
[platform] test testproc shutdown reboot

So by default ‘platform’ is used, which corresponds with ACPI S4 and is fine if it works for you. What should fix your problem if you notice too much power drain with STD:

# echo shutdown > /sys/power/disk

Now you shouldn’t find any “blinking suspended leds” on your system any longer and no further power drain should happen. More details available at $LINUX_KERNEL/Documentation/power/.

… or something like that… I planned to write a short note about how to start with using git-svn so I can provide a pointer to some of my colleagues. It turned out that git has too many nice features that you should be aware of. :) Hopefully my notes (now being a reference for myself as well, thx to gebi for all the help and feedback) are useful anyway. If you think something (more or less essential, or at least something most of us should be aware of) is missing: please feel free to mention that in the comment section of my blog entry, thanks.

Disclaimer: I’m still happy with mercurial for what I – and we at grml in general – use it: linear, but anyway distributed development. git on the other hand provides some really nice features. Rebasing and branching with git is really great – so non-linear development just works. As usual: use the right tool for the right job.

git is a bit complicate to use. Not only but especially in the beginning. On the other hand I’m not such a big friend of subversion. If you wanthave to use subversion (Graz University of Technology for example provides a svn service to their students and employees) but prefer to work with git instead you should be aware of git-svn. git-svn gives you bidirectional operation between subversion and git.

First of all make sure you have all you might need when working with git. Make sure to use a current version of git (I’m refering to version >=1.5.3). Just execute the following command line on your Debian system to install all relevant packages:

aptitude install \\
git-buildpackage git-core git-cvs git-daemon-run \\
git-doc git-email git-gui git-load-dirs git-svn \\
gitk gitweb qgit

Now let’s start with some general and basic configuration:

# Remove directories from the SVN tree if there
# are no files left behind, configure it globaly:
git config --global svn.rmdir=true

# Want some more global, personal git configuration?
for line in  \
  user.name=Michael Prokop \
  user.email=foo@example.invalid \
  color.diff=auto \
  color.diff.new=cyan \
  color.diff.old=magenta \
  color.diff.frag=yellow \
  color.diff.meta=green \
  color.diff.commit=normal \
do
  git config --global $line
done

Check out man git-config for much more details about configuration options.

First tip: set ‘g’ as an alias for git so you don’t have to type that much. I’ll write the long version in the following examples so copy/paste works for everyone. Make sure to use the short options of git itself as well: use ‘git co’ for example instead of ‘git checkout’. You can define your own aliases inside git as well – either manually in ~/.gitconfig or running something like:

git config --global alias.st status

Enough pre-configuration for now. It’s time to checkout the SVN repository:

# Check out the SVN repository and set 'svn/' as
# prefix for the branches:
git svn clone -s --prefix=svn/ \\
https://svn.tugraz.at/svn/$project foobar && \
cd foobar

# Adjust svn:ignore settings within git:
git svn show-ignore >> .git/info/exclude

# List all branches:
git branch -a

# List all remote branches:
git branch -r

# Rebase your local changes against the
# latest changes in SVN (kind of 'svn up'):
git svn rebase

# Checkout a specific branch:
git checkout $branch

Ok so far? But what do we have to do if we want to work on the upstream source and are allowed to commit/push directly to the repository? Let’s see how to work on that without using branches:

# Hack:
$EDITOR foobar

# Check status
git st[atus]

# List diff:
git diff [foobar]

# Commit it with a commit message using $EDITOR:
git commit -a

# Now commit your changes (that were committed
# previously using git) to SVN, as well as
# automatically updating your working HEAD:
git svn dcommit

But what should we do if we do not have commit rights? Let’s create our own branch and send a patch via mail to upstream:

# Make a new branch:
git checkout -b mikas_demo_patch

# and hack...
$EDITOR

# Commit all changes:
git ci -a -m 'Best patch but worst commit msg ever'

# ... and prepare patch[es]:
git format-patch -s -p -n master

# Now send mail(s) either use git-send-email:
git send-email --to foo@example.invalid *.patch
# ... or if you prefer mutt instead (short zsh syntax):
for f in *.patch ; mutt -H $f

You got a mail from someone else and would like to incorporate changes from the attached patch in your repository? Just store the mail in a seperate mailbox (use save-message in mutt for example, keybinding ‘s’ by default), then execute:

# Apply a [series of] patch[es] from a mailbox
git am /path/to/mailbox

Want to work on a seperate branch and rebase your work with upstream?

# First of all make sure to use recent sources...
# So pull when using plain git:
git pull -u
# .. or when using git-svn use:
git svn rebase

# Then create a new branch:
git checkout -b mika

# Hack:
$EDITOR

# Commit:
git ci -a -m 'Best patch but worst commit msg ever'

# Switch to master branch:
git checkout master

# Pull again when using plain git:
git pull -u
# .. or when using git-svn use:
git svn rebase

# Finally switch back
git checkout mika

# Now rebase it with plain git using:
git rebase origin/master
# ... or when using git-svn:
git svn rebase

# Now check out the last 5 commits:
git log -n5

Another branch-session might look like:

git co -b foo
$EDITOR
git ci -a -m 'foo changes'
git co master
git co -b bar
$EDITOR
git ci -a -m 'bar changes''
git co foo
git rebase bar
git log -n5
git st
git branch

Pfuhhh? Right. :) Now it’s time to check out another cool feature: git stash, which is just great when pulling into a dirty tree or when suffering from interrupted workflow. Demo:

git stash
git pull / fetch+rebase
$EDITOR # fix conflicts
git commit -a -m "Fix in a hurry"
git stash apply
git stash clear # unless you want to keep the stash

git reset rocks as well:

# List all recent actions:
git reflog

# Now undo the last action:
git reset --hard HEAD@{0}

How to get rid of branches?

# Delete a branch. The branch must be fully merged:
git branch -d remove_me_branch
# Delete a branch irrespective of its index status:
git branch -D remove_me_branch

# Delete a remote branch:
git push reponame :branch

Repack a git repository to minimize its disk usage:

git pack-refs --prune
git reflog expire --all
git repack -a -d -f -l
git prune
git rerere gc

Use git cherry to find commits not merged upstream.

Another really cool feature is the interactive rebasing: git rebase –interactive

Make sure you are aware of gitk:

… and don’t forget to set readable fonts for gitk, like:

[ -r ~/.gitk ] || cat > ~/.gitk << EOF
set mainfont {Arial 10}
set textfont { Courier 10}
set uifont {Arial 10 bold}
EOF

If you prefer a Qt based interface check out qgit.

Useful ressources:

• Google Tech Talk about Git by Randal Schwartz
• Linus Torvalds’ talk about git (there’s a Transcript of the talk available as well)
• Public Git Hosting at repo.or.cz
• Git Cheat Sheet
• git workshop at metalab by maximilian attems (PDF) [local copy]
• git talk by Bart Trojanowski (PDF)
• An introduction to git-svn for Subversion/SVK users and deserters
• Git – SVN Crash Course
• A tour of git: the basics
• Everyday GIT With 20 Commands Or So
• A tutorial introduction to git
• Git User’s Manual
• Git Guide – SourceMage Wiki
• Git Quick Reference
• Kernel Hackers’ Guide to git
• GitFAQ
• madduck’s ‘Packaging with Git’ (Git for Debian packaging)
• git docs online (manual pages)
• #git on irc.freenode.net, #git irc logs
• archive of git mailing list
• GitWiki

Currently there are some routing problems to the newsserver of Albasani.net. I can’t reach the newsserver from the system where I’m reading news, but through another system ($GATEWAY) which is located at another ISP without any problems. Solution?

ssh -L 9999:news.albasani.net:119 $GATEWAY
NNTPSERVER=localhost:9999 slrn -f $NEWSRC

Simple. No further setup changes. Just. Works.

Im Rahmen des Intensivseminars “Information Management” gibt es am 5. Dezember von 13:30 bis 15:30 Uhr im Seminarraum 1 (Kopernikusgasse 24) einen Gastvortrag der Oracle Austria GmbH an der TU Graz.

Inhaltsmäßig geht es um Informations-Management mit Schwerpunkt auf Service Oriented Architecture (SOA). Der Eintritt ist frei, da es aber im Rahmen eines Intensiv-Seminars mit beschränkter Teilnehmerzahl stattfindet, ist eine Anmeldung notwendig. Wer kommen möchte, bitte einfach eine kurze Mail an mich.

Wenn mir Jörn schon mal ein Stöckchen zum Thema "Wie benutzt Du Deine virtuellen Desktops?" zuspielt, mach ich natürlich gerne mit. :-)

Ich hab auf meinem Linux-Desktop 12 virtuelle Desktops. Die Zahl 12, weil ich genau diese mit Alt-F1 bis Alt-F12 ansteuern kann. Meine statische Belegung der Desktops schaut wie folgt aus:

• 1: Konsole, mit mehreren Tabs (nach “Zweck”, mit Namen und teilweise unterschiedlichen Farben versehen getrennt) und darin jeweils GNU screen
• 2: Browser (Opera, IceWeasel,…)
• 3: Lesekram/PDFs (acroread, xpdf,…)
• 4: Virtual Machines (Virtualbox, VMware, qemu,…)
• 5: Jabber-Client (Gajim)
• 7: Fernsehprogramm (tvbrowser)
• 8: Musik (meistens Amarok)

Die anderen Desktops werden dynamisch genutzt, je nach Applikationstyp und Art der Arbeit. Alles, was ich aber sowieso statisch nutze(n will), wird auch fix durch meinen Window-Manager (aktuell openbox) auf den jeweiligen Desktop gebunden. Denn ich verwende die virtuellen Desktops nicht nur für den schnellen Zugriff auf die einzelnen Applikationen, sondern auch, um meine Arbeitsgebiete zu trennen. Bürokram, Privates, Uni, grml,… – ich will nicht, dass mich z.B. Bürokram beim Arbeiten an grml aufhält oder ein Popup einer Applikation während dem Tippen stört. Deshalb starte ich durchaus sogar mal einen zweiten X-Server (typischerweise dwm mit einer Konsole), wenn ich wirklich meine Ruhe brauche.

Auf allen Desktops zugänglich (via Maus sowie Tastatur) sind yeahconsole, fbpanel (mit u.a. klipper und xpad) sowie gkrellm.

Zum 1. Desktop ist noch zu sagen, dass ich dort in der Konsole in einem Tab immer eine ssh-Session zu meinem Server laufen habe, wo GNU screen 24/7 läuft. Diese screen-Session sieht wie folgt aus:

• 0: Mailclient mutt auf der grml-Mailbox
• 1: Newsreader slrn auf albasani.net
• 2: Newsreader slrn auf news.tugraz.at
• 3: ehemals centericq, jetzt der Editor Vim mit notizen.txt
• 4: Mailclient mutt auf der Inbox
• 5: /var/www/grml
• 6: Sysadmin-Kram
• 7: IRC-Client irssi (mit ~10-20 Channels bzw. jetzt auch noch bitlbee, die ich mit esc-<nummer> durchschalten kann)
• 8: Newsreader slrn auf news.gmane.org

Diese Fensterzuordnungen sind leider schon so in die Finger gebrannt, dass ich wohl noch mindestens 1000mal auf das 3. Fenster wechseln werde um festzustellen, dass ich centericq seit Kurzem gar nicht mehr nutze. Die anderen Konsolenfenster in GNU screen sind dann wiederum dynamisch vergeben. Dank preexec/precmd der Zsh-Konfiguration von grml werden die Fenstertitel in der screen-Session auch automatisch passend zur gestarteten Applikation benannt. Und natürlich läuft auch in den anderen Konsolen-Tabs (die ich wiederum via alt-<nummer> direkt anspringen kann) jeweils GNU screen. :)

I usually don’t blog links to external ressources without adding any further information, but too many people I’ve met in the last few days aren’t aware of the following docs:

• Ulrich Drepper’s "What every programmer should know about memory" (PDF)
• D. J. Bernstein’s "Some thoughts on security after ten years of qmail 1.0" (PDF)
• Proceedings of the Ottawa Linux Symposium (several PDFs)

Your buddy list in ICQ (especially when using centericq/centerim) seems to be shorter than usual since a few days? Check bug 39 in centerim’s bug tracking system.

Ok, just another chance to get rid of the centericq/centerim stuff, right? One option is to use the IRC instant messaging gateway BitlBee (especially if you are used to IRC client Irssi you’ll like it :-)).

Copy/paste instructions how to set up BitlBee (my reference system is a Debian/stable system using xinetd):

# apt-get install bitlbee

# cat > /etc/xinetd.d/bitlbee << EOF
service bitlbee
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = bitlbee
        server          = /usr/sbin/bitlbee
        port            = 6667
        disable         = no
}
# /etc/init.d/xinet restart

# cat >> /etc/hosts.allow << EOF
bitlbee: 127.0.0.1
EOF

# cat >> /etc/services << EOF
bitlbee         6667/tcp
EOF

Then connect to localhost 6667 in your IRC client and start with reading ‘help quickstart’. Enjoy it.

# getSystemId
Libsmbios:    0.12.1
Error getting the System ID   :
Service Tag:  XschnippX
Express Service Code: XschnippX
Product Name: IBM System x3250 -[4364K1G]-
BIOS Version: IBM BIOS Version 1.35-[XschnippX]-
Vendor:       IBM
Is Dell:      0

disclaimer

Just a short notice: if you have to deal with the IBM Remote Supervisor Adapter (RSA) under Linux and it does not work with Firefox: use Opera instead. In Firefox the keyboard inside the remote console java applet does not work (at least on several boxes I’ve being working on) whereas it does in Opera. Oh and you definitely want to use the english keyboard layout on your local computer. Thanks for listening.

Peter Innerhofer lädt in tu-graz.anzeigen.veranstaltungen (MsgID: <fhui45$4o6$1@fstgss00.tu-graz.ac.at>):
zu einer Tor Install Party:

Hallo,

Im Rahmen des diesjährigen Netart.Community.Convention von mur.at veranstaltet der Realraum eine Tor Install Party.

Wann? am Freitag den 23.11 ab 16 Uhr (in Anschluss an den Backyard-Radio-Workshop).

Wo? Grenadiergasse 14, 3.Stock.

Tor ist ein anonymisierendes Netzwerk zum Schutz der Privatsphäre im World Wide Web. Es kann sich jeder mit dem Tor-Netzwerk verbinden und darüber anonym surfen. Aufgrund des speziellen Designs des Tor-Netzwerkes wird es fast unmöglich die Netzwerkzugriffe von einzelnen Personen zu überwachen bzw. zu analysieren.

Tor wird von verschiedensten Gruppen benutzt um ihre Kommunikationswege im Internet zu verschleiern um so einer Überwachung, staatlicher Zensur oder Industriespionage auszuweichen.

Es wird auf einfache Weise erklärt wie Tor funktioniert, wie man Tor benutzt und wie man Tor unterstützen kann, (oder: Wie setze ich einen Tor-Server auf?).

Bei Workshop wird live ein Tor-Server und ein Tor-Client aufgesetzt. Es steht auch ein Test-Server bereit an dem jeder einzeln sorglos Tor installieren kann.

Vorkenntnisse sind nicht notwendig. Wir versuchen einen allgemein verstänlichen und spielerischen Einstieg in die Thematik zu gestalten.

es zelebrieren:
Erwin Nindl
Peter Innerhofer

Wir bitten bei Interesse am Workshop um eine Rückmeldung.

Passend zum Thema kann ich euch übrigens das Buch "Anonym im Netz – Techniken der digitalen Bewegungsfreiheit" von Jens Kubieziel empfehlen.