Tag: linux

und schwupps… gleich mal ein upgrade von 4.5.8 auf 5.0.0 gemacht. seit laengerem setze ich owncloud schon als zentrale stelle fuer kalender und adressbuch ein. so faellt auch ein smartphone wechsel nicht all zu schwer 😉 (postings mit tag owncloud)

das upgrade ging natuerlich nicht ganz ohne wehwehchen vonstatten (obwohl ich diesmal mit backup der datenbank und des filesystems gut geruestet war). nach dem ersten aufruf hat das ding so ungefaehr gemeint “ich mach nun ein update auf 5.0, das kann eine weile dauern”. lange ist nichts passiert.. also nochmal aufgerufen, um dann von “owncloud ist im maintanance mode” begruesst zu werden. in den logfiles tat sich so garnichts, als ran an die suchmaschine und auch fuendig geworden.

die loesung (ich hab das “ich-gehe-auf-nummer-sicher-paket”): in der config.php den maintenance mode auf false gesetzt, apache neu gestartet, firefox cache geleert und auch neu gestartet. und schwupps war mein update durch.

ein bischen fazit: das look and feel von owncloud wird langsam aber sich immer besser. mit der neueren version des sync clients scheint das webdav nun auch etwas besser zu flutschen. zumindest synct die kiste schon seit dem ich schreibe.

owncloudies… macht weiter so! das ding wird noch brauchbar.

wenn man bei einem debian (lenny oder squeeze) php mit dem suhosin patch installiert (php5-suhosin) und nutzt, kann es z.b. fuer manche content management systeme “zu sicher” eingestellt sein. suhosin begrenzt dabei die maximale groesse der POST requests. im falle von contao fuehrt das dazu, dass manche einstellungen nicht mehr abgespeichert werden koennen und still und heimlich im error.log folgender eintrag zu finden ist:

[warn] mod_fcgid: stderr: ALERT - configured POST variable limit exceeded - dropped variable 'start' (attacker 'xxx.xxx.xxx.xxx', file '/var/www/contao/main.php')

abhilfe schafft eine vergroesserung der entsprechenden werte in der php.ini. z.b. so:

suhosin.post.max_vars = 200000 
suhosin.request.max_vars = 20000 
suhosin.post.max_value_length = 265000 
suhosin.request.max_value_length = 265000

ich wuss, dass DAS lange dauern wird…

aber gleich so lange?

ein paar mal drueber schlafen kann ich bei dem check eineer 2 TB platte mit badblocks im “schnellen” destruktiven modus…

ca. 1% in ca. 45 minuten… das wird dann wohl drei tage dauern.

beim initialen build eines raid 1 in einem neuen server mit neuen platten:

sd 2:0:0:0: [sda] Unhandled sense code
sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
        55 17 65 60 
sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
sd 2:0:0:0: [sda] CDB: Read(10): 28 00 55 17 65 5c 00 00 08 00
end_request: I/O error, dev sda, sector 1427596640
ata3: EH complete
raid1: sda: unrecoverable I/O read error for block 1405914752
RAID1 conf printout:
--- wd:1 rd:2
disk 0, wo:0, o:1, dev:sda4
disk 1, wo:1, o:1, dev:sdb4
RebuildFinished event detected on md device /dev/md/3

na toll… na wenigstens noch keine daten drauf. das macht das zurueck schicken einfacher 😉

so.. wieder was gelernt. hab ein neues backup servchen zusammen geschraubt. darin ein paar neue 2 TB platten. von debian netinst iso gebootet, installiert und beim grub in den roten fehler bildschirm gelaufen. auf der console vier war dann diese ausgabe zu sehen:

This GPT partition label has no BIOS Boot Partition

ein kurzes googlen brachte erloesung. eine bios boot partition muss also her.
in der parted shell geht das mit dem befehl

set x bios_grub on

..wobei x die partition ist, die man vorher extra dafuer eingrichtet hat.

sieht nach arbeit aus heute abend 🙁

root@kiste:~# ping domain.blubs
-bash: ping: command not found
root@kiste:~# mount
-bash: /bin/mount: Input/output error
root@kiste:~# ps ax
-bash: ps: command not found
root@bukiste ls
-bash: /bin/ls: Input/output error

notiz fuer mich selbst:

mysql_backup nutzt myqsldump, um ein backup von mysql zu machen. auf manchen meiner server gibts dann die fehlermeldung:

mysqldump: Got error: 1556: You can't use locks with log tables. when doing LOCK TABLES

als loesung einfach die entsprechende zeile (mysqldump) im script suchen und das hinzufuegen:

--skip-lock-tables

via sysadminslife

ok, ueber details kann man streiten.

seit version 4 bietet owncloud die moeglichkeit, “externes” storage einzubinden. d.h. man kann bereits vorhandene “cloudspeicher” einbinden und ueber das owncloud interface darauf zugreifen. irgendie soll das wohl mit dropbox und gdrive usw funktionieren, aber ich habs erstmal mit ftp probiert. hilfe findet man auf der seite “Custom Mount Configuration“. da steht auch nix von dropbox etc. geschrieben.

um einen ftp server einzubinden muss man die datei config/mount.php anlegen. in meinem falle mit folgendem inhalt (benutzernamen etc. sind natuerlich anzupassen);

array(
  'ich'=>array(
   '/ich/files/mountpoint/'=>array('class'=>'OC_Filestorage_FTP',
    'options'=>array('host'=>'www.ftphost.tld',
                     'user'=>'ftpUserName',
                     'password'=>'ftpPassWord'))
    	)
    )
);
?>

diese mounts kann man wahlweise fuer bestimmte user und gruppen oder auch fuer alle anlegen. details siehe link oben.
ich habe auf dem besagten ftp ca. 3000 bilder liegen. owncloud “scannt” diese natuerlich erstmal. dabei werden die dateisystem objekte erstmal mit name, datum, hashwert etc in der tabelle fscache abgelegt. wenn es sich um bilder handelt und man mit der integrierten gallery durch diese browst, legt owncloud auch noch thumbnails im userverzeichnis (unterverzeichnis “gallery”) unterhalb des “datadirectory” an.
zu weiteren spielereien bin ich noch nicht gekommen… ich finds aber irgendwie suboptimal, dass owncloud fuer meine 3000 bilder auf dem remoteserver 22672 (!) einzelne logins gemacht hat.