#!/bin/blog

May 11, 2012

Darf man die NTP-Server der PTB nutzen?

Filed under: Internet, UNIX & Linux — Tags: , — martin @ 9:34 am

Auf einer Mailingliste wurde mal wieder die Devise herausgegeben, man solle nicht ohne weiteres die NTP-Zeitserver der Physikalisch-Technischen Bundesanstalt PTB benutzen, sondern stattdessen auf pool.ntp.org zugreifen.

Ich habe diese Geschichte, die schon so lange erzählt wird, wie ich NTP kenne, für eine Urban Legend gehalten und deshalb mal bei der PTB direkt angefragt:

mir läuft schon seit vielen Jahren in Linux- und UNIX-Kreisen ein Ratschlag über den Weg, in dem es heißt, die NTP-Server der PTB seien nicht für die allgemeine öffentliche Nutzung gedacht. Stattdessen solle man sich bei anderen Quellen bedienen, wie z.B. mittlerweile bei pool.ntp.org.

Ich habe selbst leider keine Erfahrungswerte mit NTP-Servern mit Hunderttausenden oder Millionen von Clients, daher kann ich mir selbst keinen Reim darauf machen, wieviel Plausibilität ich dieser Geschichte beimessen soll.

Können Sie mir sagen, ob es für die NTP-Server der PTB irgendwelche Nutzungsbedingungen oder Einschränkungen gibt, die zu beachten sind? Gibt es Auslastungsdaten der Server, die Sie öffentlich machen können?

Daraufhin habe ich sehr schnell die folgende Antwort erhalten:

Gern können Sie unseren NTP-Zeitdienst benutzen. Bitte beachten Sie auch die Hinweise unter:

http://www.ptb.de/de/org/q/q4/q42/ntp/ntp_main.htm

Grundsätzlich sind unsere NTP-Server für die allgemeine Nutzung freigegeben. Die Auslastungsdaten stellen wir nicht öffentlich bereit. Derzeit ist es jedoch so, dass uns pro Sekunde mehrere Tausend Abfragen auf dem NTP-Port erreichen. Diese stellen aber kein Problem dar! Problematischer sind nur die Abfragen auf dem Time- und Daytime-Port, die wir daher begrenzen.

Sprich: Jedermann kann die NTP-Server der PTB ohne weiteres benutzen, um die gesetzliche Zeit der Bundesrepublik Deutschland zu beziehen. Meine Theorie, daß es sich bei den vermuteten Einschränkungen hinsichtlich ihrer Nutzbarkeit um Urban Legends handelt, war also zutreffend. :-)

March 3, 2012

Das Ende von Linux auf dem Desktop

Filed under: UNIX & Linux — martin @ 10:54 am

Mir ist, kurz gesagt, ziemlich egal, von welchem Betriebssystem meine Bash, mein Firefox und mein LaTeX geladen werden.

Und so schwänze ich schon seit bald einem Jahr die Treffs “meiner” Linux User Group, und beteilige mich auf der Mailingliste nicht mehr, weil ich dort konstant dafür angemacht werde, daß ich unterwegs ein Macbook Air mit Mac OS X benutze.

Jetzt hat es endlich den guten Linus Torvalds auf Google Plus erwischt. Er schrieb über seine Unzufriedenheit mit OpenSUSE und darüber, daß er wohl eine andere Distribution suchen muß, die auf dem Macbook Air einigermaßen rund läuft:

I gave OpenSUSE a try, because it worked so well at install-time on the Macbook Air, but I have to say, I’ve had enough. [...]
.. and now I need to find a new distro that actually works on the Macbook Air.

Hier einige der Expertenratschläge, die er darauf erhalten hat:

“It’s pretty strange that you have a Macbook Air. One leader of free software having something very closed it’s kinda disturbing.”

“I agree, but Macbook Air? Why, oh why…please get some real hardware for men…”

“Seriously, a “Macbook Air”? Might I ask, WHY? So much for principle….”

“Who uses/buys a mac anyways?”

“why is Linus using a mac?”

“Why would you use Apple hardware anyway… :/”

“Why would you use Mac? Just get Windows, and install Linux over it, something I don’t think you can do on a Mac. Even with BootCamp.”


Der Linux-Desktop wird heute von einem Großteil seiner Nutzer instrumentalisiert, um sich selbst eine vermeintliche moralische Überlegenheit gegenüber denjenigen zu verschaffen, die vermeintlich unreflektiert einfach konsumieren, was ihnen angeboten wird. Ich wurde mit einer Diskussion über Morallosigkeit konfrontiert, weil ich ein Macbook besitze. Ob jemand den ganzen Tag 1000 Linuxserver von einer Linuxworkstation administriert, oder ob er verdammt nochmal Linus Torvalds selbst ist, spielt für diese Extremisten keine Rolle.

Mit diesem oberflächlichen Linuxzirkus, mit dieser destruktiven Feindseligkeit, bringt ihr Linux auf dem Desktop nicht voran, sondern drängt es im Gegenteil noch weiter in die Nische, aus der es schon seit 20 Jahren nur ab und an zögerlich die Nase herauszustecken versucht.

Und dabei ist Linux nur ein Kernel. Linux ist vielleicht für Linus Torvalds wichtig, muß es für uns aber nicht sein. Was zählen muß, sind übergreifende Dateiformate, offene Protokolle und freie Software.

Wer aber freie Software konstruktiv voranbringen will, darf niemanden wegen eines Teils seines Stacks ausgrenzen.

June 3, 2011

Rebootless kernel updates

Filed under: UNIX & Linux — Tags: , , — martin @ 9:34 pm

It’s been a while since my last post, and this time, for a change, I have decided to produce a screencast. In which I show you what rebootless linux kernel updates with the great service from Ksplice actually look like.

This is on one of two Ubuntu 10.04 LTS system, for which I have licensed the commercial Ksplice service.

P.S.: Sorry for inflicting my foul accent upon you. ;-)

April 14, 2011

Bind OpenLDAP slapd to localhost only (on RHEL/CentOS)

Filed under: UNIX & Linux — Tags: , , — martin @ 9:24 am

Implemented on RHEL5.

In /etc/sysconfig/ldap, append:

SLAPD_OPTIONS="-h \"ldap://127.0.0.1 ldaps://127.0.0.1\""

Then issue /etc/init.d/ldap restart.

January 30, 2011

Make directory immutable on Linux

Filed under: UNIX & Linux — Tags: , , — martin @ 1:26 pm

Most of you know the immutable flag on Linux filesystems. It marks a given file in a special way that not even root can accidentally delete or modify it:

# touch /tmp/foo
# chattr +i /tmp/foo
# rm /tmp/foo
rm: cannot remove `/tmp/foo': Operation not permitted

Unfortunately it is not possible to apply the same to a directory so it can never be deleted, even when it is empty. At least not, if the directory is supposed to be usable for anything, because immutability means that there can be no files written to it:

# mkdir /tmp/foo
# chattr +i /tmp/foo
# touch /tmp/foo/bar
touch: cannot touch `/tmp/foo/bar': Permission denied

My workaround is to create a hidden file in the directory and make it immutable:

# mkdir /tmp/foo
# touch /tmp/foo/.immutable
# chattr +i /tmp/foo/.immutable
# rm -rf /tmp/foo
rm: cannot remove `/tmp/foo/.immutable': Operation not permitted

December 7, 2010

Set default ACL on Linux

Filed under: UNIX & Linux — martin @ 2:45 pm

Challenge: User1 has a world-writable directory. User2 has umask 077 set and writes into User1′s world writable directory. User1 can’t read those files.

Workaround: Short of User 2 setting his umask properly, set a default ACL on the directory:

setfacl -d -m user::rw,group::rw,other::r /path/to/User1/incoming/

June 8, 2010

Reset and disable password aging per-user

Filed under: UNIX & Linux — Tags: — martin @ 11:10 am

Long story short: High-security system, strict password rules, SSH users authenticated with keys, who don’t have valid password entries and are prompted to change their passwords.

chage -E -1 -I -1 -M -1 foo

-E removes the expiration date.
-I removes the inactivity timeout after password expiration.
-M removes the expiration date for the user’s password.

January 28, 2010

“Why is SVN so slow?”

Filed under: UNIX & Linux — Tags: , , — martin @ 11:25 am

I recently migrated a client from CVS to Subversion for his doc repository. I considered mailing this out after hearing a few complaints about speed (the repo is >1GB in size), but then decided to not send it.

All,

If you suffer from slow updates on Windoze, the following TortoiseSVN FAQ articles may offer a few insights:

http://tortoisesvn.net/node/41 “Why is SVN so much slower than CVS”
http://tortoisesvn.net/node/14 “Why is SVN slow on huge directories”

The key argument is that SVN due to its support for atomic transactions needs to do many more file operations than CVS in order to ensure integrity. This makes it slower than CVS, especially if there is an on-access virus scanner involved.

I’m keeping this on file here, just in case. ;-)

P.S.: “Why not git?” – Because GIT has a 3-step commit process (add, commit, push) that is not justifiable for this application. The cool people (like me) use git-svn anyway.

September 24, 2009

git binary merge

Filed under: UNIX & Linux — martin @ 7:54 pm

At last, I’ve found a halfway practical workflow for merging binary files. When I say “merge binary”, I mean: Either let one of the two files win, or edit both files externally (such as in OpenOffice Calc) in order to manually merge them.

If git push has failed, update the remote branch by running git fetch; git merge origin/master. If git pull has failed, the remote branch has already been updated and you’re involuntarily stuck in the middle of a merge operation.

Copy the local version of the file to a temporary name: cp test.dat my.test.dat, then check out the unmerged test.dat from remote: git checkout --theirs test.dat.

Compare the files and update test.dat to contain the desired content. Then: git add test.dat; git commit; git push. Done.

This shall now be my workflow for documentation repositories. Your mileage may vary. Objects in the mirror may be closer than they appear. Thanks for your patience.

August 21, 2009

Ethernet Bandbreite messen

Filed under: UNIX & Linux — Tags: , , , , , , , — martin @ 11:22 am

Den Datendurchsatz auf einer Ethernet-Verbindung mißt man z.B. mit NetPIPE oder mit iperf. Unter Debian sind diese unter den Paketnamen netpipe-tcp bzw. iperf installierbar.

Für die Bandbreitenmessung mit beiden Tools muß auf dem ersten beteiligen Rechner jeweils eine Serverkomponente gestartet werden:

Für NetPIPE: NPtcp
Für iperf: iperf -s

Auf dem anderen Rechner wird dann ein Client gestartet, der die Messung durchführt:

Für NetPIPE: NPtcp -h <gegenstelle>
Für iperf: iperf -c <gegenstelle>

Iperf produziert bei mir generell etwas höhere Meßwerte als NetPIPE. Wo NetPIPE bei knapp 700 Megabit aufhört, legt iperf noch eine Schippe drauf und landet bei etwas über 800 Megabit.

Wer sich über noch höhere Werte freuen will, darf sein Glück mit iperf und der Option -u (auf beiden Enden) versuchen. Damit wird die Messung nicht per TCP, sondern per UDP durchgeführt. Auf der hier gemessenen Leitung, die noch eine hochwertige Kat.5-Komponente an Bord hat, kommt iperf auf genau 1 Gigabit, was mir etwas zu sportlich vorkommt.

Des weiteren kann es sich lohnen, mit der Option -d (wieder auf beiden Enden) zu spielen, um die Performance im Vollduplexbetrieb zu testen. Dabei stinkt meine Verkabelung im TCP-Modus schrecklich ab, während im UDP-Modus das Märchen vom vollen Gigabit aufrecht erhalten wird. Ver viel Geduld hat, kann in solchen Situationen gern in die Ursachenforschung einsteigen. :-)

Older Posts »

Theme: Shocking Blue Green. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.