Archiv der Kategorie: Linux

ownCloud auf ubuntu Server installieren

Auf persönlichen Wunsch nun auch die Anleitung wie man ownCloud auf ubuntu Server installiert, sowie eine verschlüsselte Verbindung automatisch aufbaut.

Zuerst machen wir uns mit

sudo -i

zum root.

Nun müssen wir den Apache, PHP sowie SQLite installieren. Mit dem Befehl

apt-get install php5 sqlite php5-gd php5-sqlite libcurl3 php5-curl

wird alles benötigte Installiert. Der Apache wird wegen den Abhängigkeiten automatisch mitinstalliert. Nun wechseln wir mit

cd /var/www

in das Datenverzeichnis vom Apache und laden mit

wget http://owncloud.org/releases/owncloud-4.0.4.tar.bz2

das ownCloud Paket herunter. (4.0.4 war zum Zeitpunkt des Schreibens die aktuelle Version)

Entpacken Sie das Paket mit

tar xvjf owncloud-4.0.4.tar.bz2

Legen Sie nun den Datenordner an. Als Beispiel legen wir ihn im /srv Verzeichnis  an und weisen den richtigen Benutzer und Lese/Schreibrechte zu.

cd /srv
mkdir ownclouddata
chown -R www-data:www-data ownclouddata
chmod 0770 ownclouddata

Hinweis!
Auch wenn der Datenordner variabel ist, verlangt ownCloud beim Setup einen data Ordner in /var/www/owncloud/data mit oben genannten Rechten und Eigentümer, Sie müssen Ihn allerdings nicht verwenden. 

Bearbeiten Sie nun die Apache Konfigurationsdatei

vi /etc/apache2/sites-enabled/000-default

und fügen Sie am Ende der Datei über </VirtualHost>noch folgendes ein:


Options +Indexes
AllowOverride All
Order allow,deny
allow from all

Damit Dateien über 2 MB hochgeladen werden können müssen wir die php.ini noch bearbeiten. Mit dem Befehl:

vi /etc/php5/apache2/php.ini

Öffnen Sie die Datei und ändern unten stehende Werte wie folgt ab:

upload_max_filesize=8MB
upload_max_size=8MB

Nun können Sie ownCloud über der IP des Servers im Unterordner owncloud einrichten.

SSL Einrichten (mit halbwissen)

Nachfolgend der Webseite http://wiki.ubuntuusers.de/apache/SSL entommen.

Zuerst erstellen wir ein Zertifikat und tragen es dem Apache zu:

mkdir -p /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem
ln -sf /etc/apache2/ssl/apache.pem /etc/apache2/ssl/`/usr/bin/openssl x509 -noout -hash < /etc/apache2/ssl/apache.pem`.0
chmod 600 /etc/apache2/ssl/apache.pem

Nun müssen wir noch das SSL-Modul im Apache laden

a2enmod ssl

sowie den Apache neu starten

service apache2 force-reload

Jetzt müssen wir noch eine Configdatei für den SSL Zugang erstellen. Wechseln Sie in das Verzeichnis:

cd /etc/apache2/sites-available/

und duplizieren Sie die Datei default mit

cp default ssl

und bearbeiten Sie die neue Datein ssl

vi ssl

Ändern Sie diese wie folgt ab, bzw. legen Sie folgende Einträge an (Auszug gekürzt)

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
DocumentRoot /var/www

Nun müssen Sie noch die Seite aktivieren mittels
a2ensite ssl

gefolgt von einem

service apache2 force-reload

Automatisch auf verschlüsselte Verbindung

Zuerst aktivieren Sie das Modul mod_rewrite

a2enmod rewrite

Legen Sie die Datei .htaccess im /var/www Ordner an und bearbeiten Sie folgend:

RewriteEngine On
RewriteCond ...

Nun bearbeiten Sie die /etc/apache2/sites-enabled/000-default:

Options Indexes FollowSymLinks MultiViews
AllowOverride FileInfo

In der Datei /etc/apache2/sites-available/default folgendes ändern:

RewriteEngine on
RewriteRule ^/owncloud(.*)$ https://%{SERVER_NAME}/owncloud$1 [L,R]
RewriteLog "/var/log/apache2/rewrite.log"
RewriteLogLevel 2

Nun nur noch den Apache2 neu starten.

Tipp: Im Ordner /var/www/html liegt noch die owncloud tar.gz Datei. Diese können Sie nun löschen.

Chromebook zum selberbauen

Aus interesse habe ich mal das aktuelle ChromeOS auf meinem alten Netbook installiert. Offiziell gibt es allerdings keine Images von Google. Dafür gibt es einen findigen Hacker, der kompilierte ChromiumOS Images zur Verfügung stellt. Zu finden unter http://chromeos.hexxeh.net/. Dort werden zwei Varianten angeboten. Die Vanilla Version sowie die Lime Version. Letztere enthält zu dem Standardsystem noch zusätzliche Treiber.

Installation

Laden Sie das (aktuelle) Image herunter und schreiben Sie es auf einen USB Stick. Starten Sie von dort aus das ChromiumOS zu gehen Sie da Setup durch bis Sie auf dem Desktop landen. Dort tippen Sie gleichzeitig:

Strg+Alt+T

Nun öffnet sich ein Terminal. Hier geben Sie

shell

ein. Gefolgt von

install

Das Passwort lautet

facepunch

Die Installation dauert etwa 5 Minuten und löscht alles auf der Festplatte.

Danach schalten Sie den Laptop aus und ziehen den USB-Stick. Beim ersten Start dauert es etwa 1 bis 2 Minuten bis das System geladen ist. Hier müssen Sie das Setup nochmal neu durchgehen. Die nächsten Starts dauern etwa 20 Sekunden bei einer normalen Festplatte und Atomprozessor. Hardwareseitig funktioniert alles auf meinem Lenovo S10-3. Nur das Touchpad reagiert etwas hakelig. Ob das am Touchpad liegt oder am System kann ich nicht sagen.

Arbeiten mit dem System

Ansich lässt sich mit dem System recht flott arbeiten. Allerdings muss man sich damit abfinden das das ganzes OS ein reines Netzwerksystem ist. Ohne Internet geht nicht viel damit. Alles baut sich im Endeffekt um den Browser auf. Auch ist das gesammte System mit seinem Google Account verknüpft. Schon das Benutzerkonto lässt sich nicht ohne Google Account erstellen. Zudem kommt dazu, dass in der Standardeinstellung sogar die Passwörter vom Browser (verschlüsselt) auf die Googleserver gespeichert werden. Dies lässt sich zwar alles ausstellen, aber der bittere Beigeschmack bleibt trotzdem.

Fazit

Ein schnelles System, das einfach ist mit einer super Verdrahtung zu den Googe Diensten. Allerdings muss man noch dazu erwähnen das sich ChromeOS noch in der Entwicklung befindet und es sich in der Hinsicht noch viel tuen wird. An manchen Ecken wirkt das System noch etwas unfertig und inkonsistent von der Bedienung. Was die Privatsphäre angeht, muss dies wohl jeder für sich selber entscheiden. Man muss Google allerdings zugestehen, das man die Einstellungen sehr fein vornehmen kann.

syslog auf Nadeldrucker ausgeben

Da wir ja ein neues Spielzeug im fNordeingang haben, hab ich mal was gebastelt.

Ziel war es, den syslog (/var/log/messages) zu Archivierungszwecken auf einem entfernt stehenden Nadeldrucker in realtime zu sichern.  Ich habe ein paar Anleitungen gefunden wie man syslog per UDP durchs lokale Netz schickt. Habe dann aber doch was eigenes gefrickelt. Der Server läuft auf Scientific Linux der Druckerserver auf Debian.

Druckerserver (DEBIAN) einrichten

Legen Sie am besten einen extra Benutzer an und fügen Sie Ihm der Gruppe lp hinzu. Als Beispiel nenne wir mal den Benutzer drucker

# adduser drucker --ingroup lp

SSH KEY erzeugen (Scientific)

Zuerst legen wir auf dem Server / Rechner dessen syslog ausgedruckt werden soll einen SSH-Schlüssel an. Mit dem Befehl

# ssh-keygen -t rsa

legen wir einen Schlüssel an. Kein Passwort eingeben. Ansonsten kann das spätere Script nicht laufen. Den öffentlichen Schlüssel kopieren Sie mit

# ssh-copy-id drucker@druckerserver-ip

auf den Druckerserver.

Server einrichten (Scientific)

Erst einmal müssen wir ein Scipt erstellen.

# vi /usr/local/sbin/drucker.sh

Das folgende Script können Sie übernehmen.

#!/bin/bash
while [ 1=1 ]
do
tail -F /var/log/messages | ssh -i /root/.ssh/id_rsa benutzername@serveradresse "cat > /dev/lp0"  
done

(Die Schleife ist dafür da, falls einmal die Verbindung abbricht)
Speichern Sie das Script ab und machen Sie es mit

chmod +x drucker.sh

ausführbar.

Nun noch das Script an die rc.local hängen

vi /etc/rc.local

und am Ende eintragen

/usr/local/sbin/drucker.sh

Nach einem Neustart sollte der Drucker nun munter in Realtime den Log ausdrucken. Ausprobieren kann man dies auch indem man das Script von Hand zum testen startet.

Anmerkung

Das Script lässt sich natürlich auch auf andere Logs anweden. Ob es /var/log/secure ist oder ein IRC Log.

Das mit dem Internetausdrucken

Nadeldrucker mit Tweets

Mal wieder etwas neues aus dem Hackerspace fNordeingang.

Nachdem wir einen alten Nadeldrucker geschenkt bekommen haben, entsinnten wir uns doch an das Projekt aus dem Chaosdorf mit dem Nadeldrucker und der Twitteranbindung zu finden unter: http://wiki.chaosdorf.de/index.php?title=Nadeldrucker.

Das gleiche haben wir dann auch nachgebaut. Die Projektseite vom fNordeingang ist zu finden unter: http://fnordeingang.de/wiki/Twitternadeldrucker.

Hardware

Der obligatorische Nadeldrucker wird benötigt, der dann über den Parallelport an der Rechner angeschlossen wird. Sollte im Ordner /dev kein lp0 vorhanden sein muss das Modul über

modprobe lp

von Hand geladen werden, sowie in die /etc/modules eingetragen werden damit es beim hochfahren mit startet.

Mit einem

echo "Test Test 1 2 3" > /dev/lp0

sollte der Drucker eine Zeile ausgeben.

Software

Um die Tweets abzurufen brauchen wir noch den konsolenbasierten Twitterclient der sich mittels

apt-get install twidge

installieren lässt, und danach noch mit

twidge setup

eingerichtet werden muss.

Script

Im Gegensatz zu dem Chaosdorfscript läuft unseres allerdings lokal und als cronjob. Folgend das Scipt vom fNordeingang:


#!/bin/bash
(
TWEETS=$(twidge lsreplies -u -s | iconv -f utf-8 -t cp437)
if [[ -n $TWEETS ]]; then
echo "$(date)";
echo "${TWEETS}";
echo "";
echo "";
fi
) > /dev/lp0

In der /etc/crontab wird dann noch folgende Zeile angehangen. Den Pfad natürlich so ändern das er zu dem Script führt.

* *     * * *   root    /bin/bash --login /usr/local/sbin/nadeltweet.sh

Das wars. Nun sollte der Drucker jedes mal wenn jemand eine Nachricht an den eingerichteten Twitteraccount schreibt, diese Nachricht mit Zeitstempel ausgeben. Dazu ruft der cronjob jede Minute das Script auf, welches mittels twidge die Tweets abruft.

Das ganze läuft natürlich wieder auf dem Igel Winestra. Langsam kommt es mir vor das ich über nichts anderes mehr blogge. 😉

Mit dem Igel auf die Jagd

Der Aufbau mit Igel und Webcam

Letzte Woche erwähnten meine Großeltern dass sie Nachts immer geweckt würden, weil irgendetwas auf dem Dachspeicher herumläuft. Da das Aufstellen von Lebendfallen leider nichts brachte, aber auf dem von meiner Großmutter verstreuten Mehl trotzdem Spuren zu finden waren, vermutete man einen Marder oder ähnliches auf dem Dachspeicher.

Nebenbei erwähnte ich das man ja eine Kamera aufstellen könnte um mal zu schauen ob diese etwas aufnimmt und ich da ja was für hätte.

Meine Großmutter war von der Idee total begeistert  so dass ich ein paar Tage später den Igel Winestra ThinClient mit einer USB-Webcam auf den Dachspeicher aufbaute. Da die Spuren auf einer von mehreren gepuderten Mehlstelle jeden Tag neu waren, stellten wir den Igel mit Kamera darauf gerichtet auf. Da der Igel keinerlei Lüfter hat und nur ein blaues Licht, welches ich mit schwarzen Isolierband abgeklebt habe, hofften wir das uns was in die Kamera läuft.

Tag 1

Auf dem Mehl waren zwar wieder neue Spuren, allerdings wurden keine Fotos gemacht. Ich vermutete das es daran lag das auf dem Dachspeicher nur eine kleine Lampe „glühte“, so dass wir dem nächtlichen Gast noch eine zusätzliche Leselampe hingestellt haben um ihn ins Rampenlicht zu bringen.

Tag 2

Leider wieder keine Fotos trotz eingeschalteten Licht. Die Spuren waren schon wieder da und auch das Licht war stark genug gewesen. Leider war die Auslösung nicht fein genug eingestellt, sodass ich diese so einstellte, dass bei weniger Pixeländerungen ausgelöst wird, auch mit dem Risiko durch Bildrauschen ein paar mehr Falschaufnahmen zu haben weil die Sonne mal durch das Dachfenster herein kam. Dafür war in der Lebendfalle eine kleine Maus. Den Versuch Sie einzufangen und auszusetzen endete damit das diese sich beim öffnen der Falle auf und davon machte.

Tag 3

Zwei Mäuse erwischt

Endlich was auf den Aufnahmen. Nur leider kein Marder. Sondern nur 2 Mäuse die vor der Kamera rumwuselten. Und dies über mehrere Stunden verteilt.

Da meine Großeltern aber auch die letzten Tage nichts mehr gehört haben ist entweder der Marder weg, wenn er jeh da war, oder die Mäuse sind leiser geworden. Ansonsten werde ich den Igel wieder aufbauen und schauen ob doch noch was größeres auf dem Dachspeicher rumläuft.

Technische Seite

Die Aufnahmesoftware heisst motion. Ich habe darüber auch einen Artikel geschrieben (Überwachungskamera mit motion). Der Artikel ist für openSUSE geschrieben lässt sich aber im großen auf andere Distributionen verwenden. Die Option threshold musste ich von dem Standardwert 1500 auf 400 herunternehmen, da die kleinen Mäuse zu wenig „Pixel“ haben.

Igel Thinclient – Zwischenbericht

Igel Winestra – aktueller Stand

Nachdem ich nun in der letzen Woche mal mehr – mal weniger am Gerät rumgespielt habe ein paar Infos von mir wie es um das Gerät steht. Wer noch nicht weiß worum es geht sollte erst diesen Artikel von mir lesen.

Die gute Nachricht ist, dass der IGEL noch funktioniert, die schlechte, dass nicht alles so funktioniert wie ich es erhofft habe. Aber mehr dazu im folgenden Artikel:

PCI-Steckplatz

Der PCI Steckplatz ist von den Maßen her sehr knapp bemessen. Eine USB-PCI-Karte hat nur mit viel gefummel und dem kompletten auseinanderschrauben der Karte sowie des Einbaurahmens gerade so hinein gepasst. Einen Gigabit Netzwerkkarte wollte garnicht hineinpassen. Der PCI Slot ist wohl dafür optimiert den nicht vorhanden Kartenleser aufzunehmen.

Internes USB

Der interne USB-Anschluss hat nach dem Anschluss eines USB-PCI-Brackets für die PCI Blende angefangen interessante Gerüche abzusondern. Scheinbar sind die Stifte nicht wie sonst angeschlossen. Leider habe ich im Netz nichts gefunden wie die Stiftleiste richtig belegt werden. Der USB Controller hat den Kurzschluss zum Glück ohne Probleme überlebt.

RAM nachrüsten

Der RAM-Einschub unterstützt nur Singe-Side-RAM Module. Ein 1GB-Double-Side-Riegel wurde nur mit 512 MB erkannt aber funktionierte. Ein anderer Riegel wurde vom BIOS nicht unterstützt und dieses quietierte dies mit einem Dauerpiepen.

Betriebssystem

GNUstep auf dem IGEL Winestra

Der VIA C7 Prozessor ist nett gesagt sehr langsam. Damit ich ein halbwegs komplettes System installieren kann, habe ich die Flashkarte durch ein 8GB Modell aufgerüstet. Ein openSUSE mit GNUstep startet zwar relativ schnell. Leider gibt es aber kaum Pakete für GNUstep im Build Service, so dass ich im Nachhinein ein minimales Debian installiert habe, welches auch halbwegs flott arbeitet. Leider lässt sich der BeOS Nachbau Haiku nicht dazu bewegen mit dem Thinclient zu arbeiten. Es stürzt schon beim booten ab. Schade eigentlich, da bei Haiku die Oberfläche im Kernelmode läuft und so eventuell noch was Leistung rauszuholen gewesen wäre.

Update: Da GNUstep zwar ganz nett ist, aber letztendlich an der Bedienung scheitert habe ich ein LXDE installiert. Dies ist genauso schnell und verbraucht in etwa genauso wenig RAM wie GNUstep.

Spielereien

Da der TMDS Chip etwas warm wird habe ich einen passiven aufklebbaren Kühlkörper darauf geklebt. Dies ist eigentlich unnötig. Ich hatte nur noch Kühlkörper übrig.

Was noch ansteht ist die Netzwerk-LED. Dafür werde ich wohl noch ein Loch in die Abdeckung bohren. Mal sehen was sich sonst noch damit anfangen lässt. Zurzeit arbeitet die Kiste als aufgebohrter Terminal Emulator im Neusser Hackerspace.

Update 2: Arch Linux läuft unter dem Winestra auch sehr performant und so arbeitet eine Kiste nun bei meiner Mutter als Backup Server. Mit rsyncd, sshd und webmin kommt alles auf ~30 MB RAM. Auch wenn der VIA C7 beim rsync schon arg ins Schwitzen kommt. 😉 Der Winestra kann übrigens auch vom Netwerk booten. Im Hackerspace benutzen wir die auch um vom Server ein Arch Linux zu booten.

Interessante Links zum Thema:

25 Euro PC oder Thinclient für Nerds

Igel 4210 LX Winestra

Nachdem ich schon länger damit geliebäugelt habe mit einen Thinclient anzuschaffen (ehr aus der Hinsicht das die Thinclients bei der Bucht günstig zu bekommen sind und man damit rumbasteln kann) habe ich mir ein Igel 4210 LX Winestra gekauft. Das System selber ist ausgestattet mit einem 1Ghz VIA Prozessor, 256MB DDR2 RAM und einer 128 MB Compact Flash Karte als Datenspeicher. Da das System also etwas schwachbrüstig ist muss man hier schon einiges bei der Distributionswahl beachten. Es sei denn man bootet von Netwerk oder bastelt sich etwas zurecht.

Man hat nun die Wahl das Gerät aufzurüsten was ohne weiteres geht. So lässt sich das RAM auf bis zu 1 GB erweitern und die Compact Flash Karte austauschen. Hier ist allerdings auf Kompatibilität zu achten. Auch ein normaler IDE Anschluss ist am Mainboard verbaut. Allerdings muss man dann schauen wie man das Laufwerk mit Strom versorgt. Dies ist nur von einer externen Stromversorgung möglich. Praktischerweise sind Pins für USB intern vorhanden sowie ein aufgelöteter Temperaturmesser. Dazu ist eine PCI Schnittstelle verbaut, so das sich eine Erweiterungskarte einbauen lässt. Die CPU ist passiv gekühlt und somit ist das gesammte Gerät geräuschlos. An der Frontblende sind Anschlüsse für eine LED vorhanden die die Netzwerkaktivität anzeigt. Diese muss allerdings aufgelötet werden.

Hardware

Igel Mainboard

Folgend ein paar Informationen über die verbaute Hardware. Eingebaut ist wie erwähnt ein  VIA C7 Prozessor mit 1 GHz (128KB Cache, MMX, SSE, SSE2). Die Grafikkarte Der TMDS Chip ist ein Silicon Image SIL 164CTG64. Der Ethernetcontroller, sowie Audio sind im Southbridge untergebracht. Dabei handelt es sich um ein VIA VT8235. Der Verbrauch des Systems soll bei Auslastung um die 20 Watt liegen.

Grün = IDE Stiftleiste, Rot = USB Stiftleiste, Blau = Temperatursensor, Orange = PCI Slot

Linuxdistributionen

SliTaz Linux

Als Linuxdistribution fallen die großen Majordistributionen wie openSUSE, ubuntu oder fedora etc. leider aus, da sich diese nur mit sehr viel Aufwand auf 128 MB Speicher mit grafischer Oberfläche installieren lassen. Aus diesem Grunde habe ich mich für SliTaz Linux entschieden, welches bei der Standardinstallation knapp 110 MB benötigt so das noch etwas Luft vorhanden ist. Durch entfernen von ein paar Pakete kann man sogar noch etwas herausholen.

Hacken

Da ich das Gerät erst seit ein paar Tagen besitze werde ich wohl noch etwas damit rumbasteln. Da das Gerät einen internen USB Anschluss hat werde ich eine alte USB Blende benutzen um diese an die USB Steckleiste anzuschließen und daran einen USB-Stick. Das Kernel wird dann auf die Compact Flash Karte geschrieben (wegen Treiber) und die restlichen Daten auf den USB Stick. Dies ist eine wesentlich kostengünstigere Methode, als eine neue große Compact Flash Karte zu kaufen. Das RAM werde ich noch auf 1 GB mit einem alten Arbeitsspeicherriegel erweitern. So sollte sich auch eine normale Distribution aufspielen lassen. Falls noch Platz bleibt könnte man noch eine TV Karte oder zusätzliche Netzwerkkarte einbauen. Mehr dazu werde ich hier später noch schreiben.

Interessante Links zum Thema

YouTube Video über das System > http://www.youtube.com/watch?v=v1LlTvM2r_E

ownCloud auf CentOS, RHEL oder SL installieren

Nachdem ich bereits einen Artikel für openSUSE geschrieben habe, hier noch eine ausführliche Anleitung für die Installation unter CentOS, RHEL sowie Scientific Linux. Die Installation unter openSUSE ist im übrigen wesentlich einfacher. Für diejenigen die noch nicht wissen was ownCloud ist verweise ich auf den Artikel der Wikipedia zu finden unter http://de.wikipedia.org/wiki/OwnCloud. Die Anleitung unten müssen Sie einfach durcharbeiten.

Alle Befehle werden als root ausgeführt.

Zuerst müssen wir einige Pakete nachinstallieren (falls noch nicht installiert).

yum install httpd mod_perl php-mbstring perl-string-Multibyte php php-mysql

Abhängigkeiten werden automatisch aufgelöst. Nach der Installation wechseln wir mit

cd /var/www/html

in das Webverzeichnis vom apache. Laden Sie mit

wget http://owncloud.org/releases/owncloud-2.0.1.tar.bz2

die aktuelle Release herunter. Der Link oben war zum Zeitpunkt des Artikels aktuell. Nach dem Herunterladen entpacken Sie das Verzeichnis mit

tar xvjf owncloud-2.0.1.tar.bz2

Dann ändern Sie mit

chown -R apache:apache /var/www/html

den Verzeichnisbesitzer sowie mit

chmod 0770 /var/www/html/owncloud/data

die Schreibrechte des späteren Datenverzeichnisses von ownCloud.

Nun müssen wir den apache noch so Konfigurieren, dass die gespeicherten Dateien nicht direkt herunterladbar sind. Öffnen Sie die Konfigurationsdatei mit

vi /etc/httpd/conf/httpd.conf

und ändern Sie die unten stehende Optionen wie folgt ab (Sie müssen die Taste i drücken um in den Einfügemodus zu gelangen; speichern mit ESC :wq):


Options None
AllowOverride None
Order allow,deny
Allow from all

und fügen Sie am Ende der Datei noch folgendes ein:


AllowOverride All
Order allow,deny
allow from all


Damit Dateien über 2 MB hochgeladen werden können müssen wir die php.ini noch bearbeiten. Mit dem Befehl:

vi /etc/php.ini

Öffnen Sie die Datei und ändern unten stehende Werte wie folgt ab:

upload_max_filesize=8MB
upload_max_size=8MB

Nun müssen Sie noch mit

system-config-firewall-tui

die Firewall einrichten und Port 80 freigeben. Klicken Sie auf Anpassen und wählen Sie den Punkt WWW (HTTP) aus (weiter unten in der Liste). Dann auf Schließen > OK > Ja.

Nun können Sie ownCloud mit

service httpd start

starten. Erreichbar ist es unter

IP.des.Servers/owncloud.

Tipp: Im Ordner /var/www/htmlliegt noch die owncloud tar.gz Datei. Diese können Sie nun löschen.

Interessante Links zum Thema

Scientific Linux – oder die Suche nach der Serverdistribution

Nachdem es ja wie bekanntlich Richtung Jahresende geht, habe ich mir zu Weihnachten eine Hardware-RAID-Karte von 3ware gegönnt, um genauer zu sein eine 3ware 9650SE-2LP. Auf dieser läuft nun die Systemplatte(n) im RAID1 Verbund. Die Platten mit den Daten lasse ich weiter einzeln laufen. Diese werden jede Woche einem mit rsync abgeglichen. Zeitkritische Daten liegen auf der Systempartition.

Da ich nun eh schon am Server dran war habe ich mir Gedanken gemacht inwieweit es sinnvoll ist openSUSE weiterhin auf dem Server zu betreiben. Nicht aus Gründen des Systems sondern aus der Sicht des Supportzeitraums. Spätestens Ende 2012 müsste ich mir Gedanken über in Upgrade auf die nächst höhere Version machen. Das dies meistens nicht klappt ist wohl bekannt (siehe Versionsprung auf 11.4 mit dem AppArmor Bug und SMB). Da ich allerdings auch kein Debian(derivat) verwenden wollte blieb im Endeffekt nur noch CentOS und Scientific Linux übrig. Ich habe mich dann letztendlich für Scientific entschieden, da dort die Updates schneller gepackt werden.

CentOS oder Scientific

Scientific Linux

CentOS und Scientific sind beides Nachbauten von RHEL. Da Red Hat die Quellpakete offen legen (muss), kann daraus eine Distribution gepackt werden die binärkompatibel mit RHEL ist. Und da RedHat seine Distribution 5 bzw. 7 Jahre mit Updates versorgt, können CentOS und Scientific die Updates einfach verpacken und ausliefern. Zwar habe ich kein Support durch RedHat, diesen werde ich aber bei mir Zuhause wohl kaum benötigen.

Scientific Linux

Wie schon erwähnt ich Scientific Linux ein Klon von RHEL. Gebaut wird die Distribution zum großen Teilen von CERN, Fermilab, ETH Zürich, und dem DESY. Diese haben sich zusammenschlossen um auf einer Basis eine eigene Distribution zu schaffen, damit nicht jede Institution ihre eigene Distribution pflegen muss. Mehr dazu findet sich auf der Wikiseite von Scientific Linux.

Servereinsatz

Auf dem Server macht sich Scientific gut, auch wenn ich manch praktische Dinge von openSUSE vermisse. Das Einrichten von rsync ist etwas aufwendiger. Das voreingestellte SELinux ist bisweilen (für mich) unbrauchbar. Weder rsync noch SMB ließen sich mit den voreingestellten SELinux Regeln benutzen. Auch nachdem ich die Regeln so geändert  habe das es laufen sollte, lies sich rsync immernoch nicht verwenden. Ich habe SELinux dann einfach vom System genommen. An der Stelle finde ich AppArmor bei weitem einfacher zu konfigurieren und warten.

Desktopeinsatz

Scientific Linux Screenshot

Auf dem Desktop kann ich Scientifc Linux zum Teil empfehlen. Es kommt darauf an was machen möchte. Das KDE liegt in Version 4.3 vor. Neuere Versionen müsste man sich selber kompilieren und aktualisieren. Das Gnome liegt in Version 2.28 vor und macht einen stabilen Eindruck. Für Arbeitsplatzrechner oder für einfache Arbeiten ist der Desktop völlig in Ordnung. Wer allerdings „bleeding edge“-Software haben möchte sollte dann doch lieber zu einer schneller veröffentlichenden Distribution wie openSUSE oder Fedora wechseln. Ansonsten bekommt man ein stabiles System, das für die normalen Office und Internetanwendungen völlig ausreichend ist. Sollte man Scientific für den Desktop verwenden und hat nicht mehr als 4 GB RAM empfehle ich die 32bit Version, da es dort mehr Pakete für gibt die man sich sonst extra raussuchen muss. CentOS und RHEL Paketquellen können eigentlich ganz normal benutzt werden da alle Distributionen zueinander kompatibel sind.

Interessante Links zum Thema:

Server nur ohne angemeldeten Benutzer herunterfahren

Wie bestimmt in jedem Hackerspace oder manchen Büros stehen dort Server die eigentlich nur über den Tag hinweg genutzt werden und abends oder bei „Ladenschluss“ heruntergefahren werden können. Zwar ist es kein Problem die Einstellungen in den ACPI Config-Dateien so vorzunehmen das der Server beim drücken des Power-Knopfes herunterfährt, allerdings würden dann alle Nutzer, die noch (von extern über einen SSH Tunnel) auf dem Server sind, rausgeschmissen. Damit man trotzdem den Server per Tastatendruck ohne sich extra per ssh anzumelden herunterfahren kann gibt es eine kleine Shellscriptabfrage die man einbauen kann. Gefunden habe ich diese auf linux-club.de. Sie bewirkt, dass der Server per Tastendruck nur heruntergefahren wird wenn kein Nutzer mehr einen Tunnel zum Server offen hat. Ist dies der Fall und der Power-Knopf wird gedrückt, läuft der Server trotzdem weiter und der root bekommt eine E-Mail das der Power-Knopf betätigt wurde. Dei nötigen Schritte sind recht simpel:

Kontrollieren Sie vorher ob das Paket acpid installiert ist.

Öffnen Sie als root die Config-Datei für den Powerbutton mit dem Befehl

vi /etc/acpi/events/power_button

und ändern sie den Eintrag

action=

so ab das dort

action=sh /root/bin/poweroff.sh

steht (mit i kommen Sie in den Eingabemodus, zum speichern Esc und dann :wq). Das Script poweroff.sh erstellen wir noch später. Sie können es auch woanders speichern. In diesem Falle müssen Sie nur den Pfad ändern.

Mit dem Befehl vi /root/bin/poweroff.sh erstellen Sie das Script und öffnen gleichzeitig den Editor. Drücken Sie i um in den Eingabemodus zu gelangen und tragen Sie folgendes ein:

#!/bin/bash
r=`who -u`
if [[ $r != "" ]];
then echo "Der Powerknopf wurde gedrückt" | mail -s "Powerknopf" root@localhost
else poweroff
fi

Nun speichern Sie das Script ab (zum speichern Esc und dann :wq). Jetzt müssen Sie das Script noch ausführbar machen.

chmod +x poweroff.sh

Nun kann der Server nur noch heruntergefahren werden wenn keiner mehr auf dem System angemeldet ist. Sollte trotzdem der Powerbutton betätigt werden während noch jemand angemeldet ist wird dem root eine Mail zugeschickt, dass der Knopf betätigt wurde. Der Befehl kann aber auch einfach durch ein

exit 0

ersetzt werden, falls keine Mail erwünscht ist.