Veni, Vidi, VISA

Diese Frage wurde mir per Mail gestellt und auf meine Aussage [...] allein schon deswegen damit ich nicht ständig *BSD anstelle von Linux installieren muss [...] und meinen Rant gegen Debian 6.0 "Squeeze" verwiesen.
Die meisten Firmen wollen vorzugsweise das System, das sie in der restlichen Umgebung einsetzen (bis auf einige Ausnahmen) und das ist zum Großteil Linux, wobei leider nur sehr wenig Linux auf Workstations einsetzen. Ich werde i. d. R. auch nicht dafür bezahlt eine Workstation für eine Sekretärin oder einen Desktop für einen CADler aufzusetzen und kann auch nur Empfehlungen aussprechen was das OS betrifft. Am häufigsten wurde bisher Debian eingesetzt; aber nicht weil extremst Stabil und so, sondern weil es schnell zu installieren ist und eine umfangreiche Paketsammlung enthält. Außerdem kann man es am besten verkaufen, weil es den Ruf einer "Profidistribution" hat und auf vielen Architekturen läuft. NetBSD fristet bei meiner Arbeit (leider) ein Nischendasein (letztes Jahr genau dreimal installiert/konfiguriert); Free- und OpenBSD kamen häufiger zum Einsatz, wobei die zum Teil auch als "Auswahlsystem" bei Vservern genutzt wurden.
Sobald es sich allerdings um hochsichere Systeme dreht, rate ich jedem von Linuxdistributionen ab weil der Aufwand den Nutzen übersteigt. Bei *BSD hat man den Vorteil das man alles aus einer Hand bekommt; sprich: Kernel und Userland. Bei Linux wird der Kernel unabhängig von der Distribution entwickelt und deswegen dauert es auch länger bis Bugfixe in die Distribution einfließen (was durch das Fehler einer offiziellen Announce seitens @kernel.org zusätzlich noch verzögert wird). Dazu kommt noch das z. B. Debian Probleme provoziert; ist zwar jetzt etwas reißerisch geschrieben, aber sinngemäß. Bei "lenny" wurde die Verwendung von aptitude(8) empfohlen, während man ein Release später - also "Squeeze" - wieder apt-get(8) für die interaktive Paketverwaltung empfohlen wird. Ich wage mal zu behaupten, dass ich dieses Jahr des öfteren mit Systemen zu tun haben werde, die aufgrund der abwechselnden Nutzung von apt-get(8) und aptitude(8) kaputtoptimiert wurden. Dazu kommt noch das die Backports jetzt offizieller Bestandteil von Debian sind und Nutzer dazu motiviert werden auf diese zurückzugreifen, obwohl in der Vergangenheit in Foren, Newsgroups, Mailinglisten, .. davor gewarnt wurde Stable, Unstable und Testing zu mischen. Ich habe im Laufe der Zeit schon einige Male "aber das stand so auf der Homepage!" gehört wenn ich gefragt habe wieso $FOO $BAR gemacht hat (nicht nur in Bezug auf Debian).
Einige Firmen sind sich dessen auch bewusst, aber nehmen das Risiko in Kauf, weil sie in ihrem Umfeld eine bestimmte Software aus dem aktuellen Branch benötigen, die über das Paketmanagement verwaltet werden kann. Gentoo kommt nur in Ausnahmefällen zum Einsatz, weil jegliche Software aus den Sourcen kompiliert werden muss und die Ressourcen zum Teil anderweitig benötigt werden. Zu guter Letzt kommt es auch darauf an welche Hardware eingesetzt wird. Auch wenn *BSD noch so gut für den Einsatzzweck geeignet gewesen wäre, bringt es nichts wenn die Hardware nicht unterstützt wird. Das ist wieder ein Punkt für Linux, da hier Treiber für mehr (und auch neuere) Geräte vorhanden sind. Lustig wird es dann erst bei proprietären Treibern bzw. Software die einige Distributoren aus Lizenzgründen als proprietär einstufen.
Bei "richtigen" Hochsicherheitssystemen kommt dann allerdings kein Linux oder *BSD zum Einsatz, sondern da werden nach TCSEC evaluierte Systeme wie Trusted Solaris, Ultrix, HP-UX oder AIX eingesetzt.

Nachdem ich im vorherigen Eintrag geschrieben habe das ich nicht ständig *BSD anstelle von Linux installieren muss wenn es sich um sicherheitsrelevante Systeme dreht, haben mich schon einige Mails erreicht wo mir erklärt wurde, das man auch Linux auf solchen Systemen verwenden kann.
Stimmt auffallend. Die Frage ist nur ob man das auch wirklich will? Das kein System wirklich sicher ist, steht außer Frage (mal XTS-400 und diverse TCSEC-B1 - Systeme mal außer Acht gelassen) und das Sicherheitslücken gefunden werden lässt sich bei komplexen Systemen nicht vermeiden. Aber was ein absolutes KO-Kriterium sein kann, ist, wie auch gefundene Sicherheitslücken reagiert wird. Bei *BSD (damit ich mich auch den vorherigen Eintrag beziehe) gibt es dafür Mailinglisten und Advisories auf der Homepage wo man sich informieren bzw. auf dem laufenden halten kann. Bei Linux gibt es weder noch; nur einen kurzen Log im git-log. Gut.. besser als nix werden sich jetzt einige denken, aber das ist für Admins alles andere als auch nur irgendwie brauchbar. Ein Admin hat i. d. R. keine Zeit um sich ein Repo zu clonen und dort in den Shortlogs nach Änderungen Ausschau zu halten die sich auf Sicherheitslücken beziehen. Und - auch wenn ich jetzt einige enttäuschen muss - es bringt auch nicht viel das z. B. Debian die Mailingliste debian-security-announce@ hat, wo man über Sicherheitslücken benachrichtigt wird. Deren Aufgabe ist es, Patche über ihr Paketmanagementsystem verfügbar zu machen, damit sie eingespielt werden können. Aber das können sie erst, nachdem der Patch auch verfügbar ist.
Wenn eine bekannte Sicherheitslücke über zwei Monate lang nicht behoben wird, dann ist das absolut untragbar und die Tatsache das in keiner Art und Weise veröffentlicht wird, dass es sich um die Behebung eines sicherheitsrelevanten Bugs handelt, ist für mich ein Grund meinen Kunden Linux auf sicherheitsrelevanten Systemen als letzte Möglichkeit zu empfehlen (und selbst da nur mit Einschränkungen).

Debian:

$ dpkg --get-selections \* > /tmp/PAKETLISTE

$ dpkg --set-selections < /tmp/PAKETLISTE

$ apt-get dselect-upgrade

RPM:

$ rpm -qa > /tmp/instpackages

$ yum -y install $(cat /tmp/packages)

Gentoo:

$ emerge -av $(cat /var/lib/portage/world)

*BSD:

$ pkg_info > /tmp/instpackages

$ for i in `awk '{print $1}' /tmp/instpackages` ; do echo pkg_add -v $i ; done

ArchLinux:

$ pacman -Qqe > /tmp/instpackages

$ pacman -S $(cat /tmp/instpackages)

Crux (Danke an teK!):

$ prt-get listinst > pkglist

$ for i in `cat pkglist`;do prt-get depinst "$i";done

Slackware:

$ ls /var/log/packages > /tmp/instpackages

$ for foo in $(cat /tmp/instpackages); do installpkg $foo ; done

Das meiste war ausm Kopf zusammengeschrieben; Fehler/Verbesserungen einfach als Kommentar dalassen (gleiches gilt auch fuer Distributionen die ich vergessen hab).

http://www.pro-linux.de/news/2007/11319.html (via ./deiflisch).

Sry, aber wayne..?! Linspire zieht Xandros und Novell/Suse nach. Und? Geht die Welt jetzt unter? Debian-Nazis wissen natuerlich schon jetzt das Debian das niemals machen wird und der Rest jammert rum. Was mich an Linuxdistributionen stoert, ist, dass jeder Distributor sein eigenes Sueppchen kocht. Halbwegs einheitliche Init-Scripte? Aehnliches Runlevel-Prinzip? Fehlanzeige. "Linuxkentnisse" alleine reichen schon lange nicht mehr wenn man beruflich mit den verschiedensten Distributionen arbeiten muss. Das man sich mit "seiner" Distribution auskennt, ist schon klar, aber welcher Gentoo-User kann auf Anhieb ein Init-Script fuer einen optionalen Daemon unter Debian schreiben? Welcher Debian-User kann ohne nachzulesen ein Spec-File fuer rpm(8) unter Suse schreiben?
Ich habe allein dieses Jahr schon 10 Firmen ~80 Server von Linux auf Free-/OpenBSD umgestellt. Wieso? Weil sie entweder mit der Administration an sich nicht zufrieden waren, es keine Softwareupdates gab, die Lizenz sich geaendert hat oder das System so aufgeblaeht war, dass das "Abspecken" laenger gedauert hat, als die Installation und Konfiguration an sich (oder es war so spartanisch das man etliches nachinstallieren musste). Das Linux einige "Sonderheiten" hat, die unter BSD nicht zur Verfuegung stehen, ist mir schon klar (Framebuffer, kexec, ..), aber ich habe noch keinen Admin gesehen, der ernsthafte Schwierigkeiten bei der Umstellung auf BSD hatte.

Mir persoenlich ist es egal wer welches System nutzt (das soll jeder selbst entscheiden), aber das Nachtrauern um irgendwelche Linuxdistributionen ist sinnbefreit; die Distributoren haben sich so entschieden; wieso auch immer. Fakt ist, dass es genuegend freie Systeme/Distributionen gibt.

Den Hinweis auf den Beitrag Pro-Linux: Linux bald nur noch mit eingebauter Microsoft-Lizenz? habe ich heute per Email bekommen; zusammen mit der Frage: "Was machst Du wenn es soweit kommt?" (zur genaueren Erklaerung sei hier noch gesagt das sich "[..] wenn es soweit kommt?" darauf bezieht, dass einige Linuxdistributoren mit M$ kooperieren).

Ich seh jetzt schon wieder Steine fliegen, aber mir persoenlich ist das ziemlich relativ. Auf meinen eigenen Workstations laeuft LFS 6.0 nur, weil ich es interessehalber ausprobiert installiert habe. Mein primaeres Workstationsystem ist OpenBSD (schon seit Release 2.1). Ich kann problemlos Linux verzichten; es waere zwar schade und bedauerlich wenn sich einige Distributionen in diese Richtung entwickeln, aber man kann immer noch Distributionen nutzen, die nach wie vor frei sind. Einige User heulen aber statt dessen lieber rum und beschweren sich ueber alles moegliche. Das ist IMO vergleichbar als wuerde man auf der Strasse einen Haufen Hundescheisse sehen und absichtlich reinspringen damit man einen Grund hat sich zu beschweren.

$ export PKG_PATH=" ftp://ftp.leo.org/pub/OpenBSD/$(uname -r)/packages/$(uname -m)"

$ echo $PKG_PATH

 ftp://ftp.leo.org/pub/OpenBSD/3.9/packages/i386

$ pkg_add -ui -F update -F updatedepends

No packages available in the PKG_PATH

Looking for updates: complete

Cannot find updates for apr-1.0.1p2 [...]

Proceed? [y/N] y

$ uname -sr 

OpenBSD 3.9

Was lernen wir daraus? Richtig. PKG_PATH sollte nicht mit einem Leerzeichen beginnen.

option  WS_KERNEL_FG=WSCOL_GREEN    # Vordergrund (Schriftfarbe)

option  WS_KERNEL_BG=WSCOL_BLACK    # Hintergrund

Anschliessend den Kernel neu kompilieren und beim naechsten Boot sind die Bootmessages gruen auf schwarz. Steht aber auch in der Manpage von wscons(4) im Abschnitt Other options:.

Wenn obiges der Fall ist, sollte man vielleicht mal ln -s /usr/local/libexec/postfix/ /usr/libexec/postfix eingeben ^^ "chown: /usr/libexec/postfix: No such file or directory" vollständig lesen

Und zwar unter OpenBSD mit lighttpd und SQLite. Wie man PHP installiert hab ich hier schon erklaert und der Rest ist noch einfacher.

$ cd /usr/ports/databases/sqlite3 && make && make install clean

$ wget http://kent.dl.sourceforge.net/sourceforge/php-blog/serendipity-1.0-beta3.tar.gz

$ tar xvzf serendipity-1.0-beta3.tar.gz

$ mkdir /home/www/blog

$ mv serendipity/* /home/www/blog

$ $BROWSER http://domain.invalid/blog/index.php

"S9Y mal anders.." vollständig lesen

Hoert sich eklig an; is es auch (PHP stinkt!!!111! (Insider)). Wenn man mit pkg_add php5-core PHP installiert, wird PHP 5.0.5 installiert und ein php -v gibt folgendes aus

(dope@dreckskind) : (~): php -v

192.168.1.6 45862 22

PHP 5.0.5 (cli) (built: Mar  1 2006 16:46:00)

Copyright (c) 1997-2004 The PHP Group

Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies

Sieht auf den ersten Blick korrekt aus.. aber eben nur auf den ersten Blick. PHP 5.0.5 (cli) (built: Mar 1 2006 16:46:00) arbeitet nicht mit lighttpd zusammen, weil man laut dem hier fastcgi benoetigt. Das Lustige daran ist nur, dass unter OpenBSD kein Package und kein Port dafuer existiert. Ergo muss man entweder --enable-fastcgi in /usr/ports/www/php5/core/Makefile hinzufuegen oder PHP herunterladen und selbst kompilieren. Ricktig muss es naemlich so aussehen

(dope@dreckskind) : (~): php -v

PHP 5.1.4 (cgi-fcgi) (built: Jun  6 2006 12:08:24)

Copyright (c) 1997-2006 The PHP Group

Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

(dope@dreckskind) : (~):

Wenn man sich fuer letzteres entscheidet, sollte man aber "--prefix=", "--program-prefix=", .. anpassen, weil dieser Dreck nichtmal ein uninstall-Target im Makefile hat. Danach noch

fastcgi.server             = ( ".php" =>

                               ( "localhost" =>

                                 (

                                   "socket" => "/tmp/php-fastcgi.socket",

                                   "bin-path" => "/usr/local/bin/php"

                                 )

                               )

                            )

in die lighttpd.conf und den Server neu starten; dann laeuft auch PHP und kann wieder entfernt werden.