Tag: linux

im linux mint 17.3 repository findet sich momentan nur ein alter owncloud desktop client (1.5.0). wenn man versucht, sich damit an einer aktuellen owncloud installation anzumelden, bekommt man nur die fehlermeldung “Wrong Crendentials”.

um einen aktuellen owncloud client zu installieren muss man die datei /etc/apt/sources.list.d/owncloud-client.list (ggf. anlegen und) mit folgendem inhalt fuellen:

deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.04/ /

danach diese befehle ausfuehren:

sudo apt-get update
sudo apt-get install owncloud-client

wenn beim “apt-get update” ein fehler kommt bezueglich eines fehlenden keys mit der ID 977C43A8BA684223, dann kann man diesen wie folgt hinzufuegen:

gpg --keyserver pgpkeys.mit.edu --recv-key 977C43A8BA684223
gpg -a --export 977C43A8BA684223 | sudo apt-key add -

…danach nochmal die obenstehenden apt befehle ausfuehren

noch eine nummer einfacher als meine bisherige beschreibung:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout 'domain_tld.key' -out 'domain_tld.csr' -subj '/CN=domain.tld/C=DE'

mein opsview hat die tage wieder mal gestreikt. ich erinnerte mich, doch irgendwo schonmal was aufgeschrieben zu haben. in den entwuerfen meines blogs bin ich fuendig geworden. wie man am datum der logeintraege sehen kann, ists schon ein paar tage her. ich hab das ganze mal aktualisiert und voila.. da isses:

####

heute morgen hat mein nagios bzw. opsview seinen dienst quittiert. im logfile waren solche eintraege zu finden:

[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796429.397065 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796429.397065
[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796433.896315 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796[2015/04/12 07:38:50] [nrd] [WARN] 2015/04/12-07:38:50 Server closing!

ok, die mysql datenbank ist 22GB gross und die tabelle ‘nagios_servicechecks’ hat rund 60 millionen eintraege. was der limitierende faktor war, konnte ich auf die schnelle nicht rausfinden. normalerweise sollten in dieser tabelle nur daten von einer woche vorgehalten werden. also in mysql den befehl ausfuehren:

DELETE FROM nagios_servicechecks WHERE start_time <= '2014-07-01 00:00:00';

ursache: fehlende cronjobs! bei der letzten migration auf einen anderen server sind die entsprechenden crontab eintraege fuer den nagios user "verloren" gegangen.
dieser cronjob sollte fuer den user nagios eingerichtet sein:

11 4 * * * . /usr/local/nagios/bin/opsview_master_housekeep

fuer den dns server powerdns gibt es die administrationsoberflaeche “poweradmin“. die auswahl solcher tools ist nicht sonderlich gross… das duerfte die einfachste sein. irgendwann wirds soweit sein, dass boese buben das webinterface entdecken und versuchen einzubrechen. mit fail2ban kann man da ein bischen gegensteuern und nach fehlgeschlagenen loginversuchen die ip per iptables zu sperren.

in der datei “inc/config.inc.php” muessen dazu diese werte gesetzt sein:

$syslog_use = true;
$syslog_ident = 'poweradmin';

das ergibt dann bei fehlgeschlagenen logins im syslog eintraege wie diesen:

Feb  2 05:36:02 host poweradmin: Failed authentication attempt from [xx.xxx.xx.x]

weiter muss eine datei namens “/etc/fail2ban/filter.d/poweradmin.conf” angelegt werden mit folgendem inhalt:

[Definition]
failregex = poweradmin\: Failed authentication attempt from \[\]
ignoreregex =

und die “/etc/fail2ban/jail.conf” erweitert um folgenden eintrag:

[poweradmin]
enabled  = true
port     = http,https
filter   = poweradmin
logpath  = /var/log/syslog
maxretry = 3

und nach einem…

/etc/init.d/fail2ban restart

…sollte das auch schon funktionieren.

um bei mails, welche das eigene mailsystem verlassen, ein paar header aus der mail zu entfernen, die niemanden in der boesen weiten welt was angehen, in der datei /etc/postfix/main.cf einfuegen:

header_checks = regexp:/etc/postfix/header_checks

und die datei /etc/postfix/header_checks mit folgendem inhalt anlegen:

/^Received: .*\(Authenticated sender:.*/ IGNORE
/^Received: .*\.internal\.domain\.tld.*/ IGNORE

die erste zeile schmeisst die header weg, die durch die authentifizierung beim smtp versand hinzugefuegt werden. (falls beim fuer smtp auth zustaendigen postfix in der main.cf der paramaeter “smtpd_sasl_authenticated_header = yes” gesetzt ist).

die zweite zeile schmeisst alle recived header weg, die von internen mailservern hinugefuegt wurden. schliesslich geht die struktur niemanden was an.

weil das noch nicht ganz richtig war, hier nochmal etwas angepasst:

# erstmal backup machen
cd /var/www/sites/kundexy
mysqldump -p -h   > backupdb-$(date +%Y%m%d%H%M).sql
tar -czvf backup-$(date +%Y%m%d%H%M).tar.gz  --exclude files/cloud
# dann update laden und installieren
cd verzeichniswebseite
curl -L https://download.contao.org/3.5.6 | tar --strip-components=1 -xzp
chown . <../verzeichniswebseite/> -R
# und wenn alles danach noch funktioniert, den kram wieder loeschen:
rm core-3.2.16.tar.gz
rm ../201412211004.sql # ersetzen mit dem aktuellen dateinamen
rm ../201412211004.tar.gz # ersetzen mit dem aktuellen dateinamen
# feddich!

tagelang habe ich mich mehr oder weniger erfolgreich erfolglos mit der dnssec implementierung in bind herumgschlagen. mittendrin kam ein kommentar von jonne, welches mich dann doch inspirert hat, mal powerdns anzuschauen. und was soll ich sagen? vergesst die wakeligen pakete in debian fuer bind und die dnssec-tools und nehmt powerdns. (natuerlich nicht den alten in debian stable, sondern ein aktuelles paket welches sich ohne grosse abhaengigkeiten installieren laesst.)

den folgenden absatz habe ich erst nach dem eigenen, in rekordzeit erstelltem test-setup gelesen:

In addition, the PowerDNS Authoritative Server is the leading DNSSEC implementation, hosting the majority of all DNSSEC domains worldwide. The Authoritative Server hosts at least 30% of all domain names in Europe, and around 90% of all DNSSEC domains in Europe.

und ganz ehrlich… ich weiss aus eigener erfahrung auch genau warum.

moeglicherweise gibts demnaechst auf diesem kanal ein kleines howto dafuer.

da sich seit dem upgrade von 4 auf 5 ein paar kleinigkeiten geaendert haben… hier nochmal mein braindump fuer das patchlevel update von z.b. 5.0.1 auf 5.0.2

apt-get install -y libmime-base64-urlsafe-perl libauthen-sasl-perl libxml-libxml-perl libxml-libxslt-perl
cd /opt
wget http://ftp.otrs.org/pub/otrs/otrs-5.0.2.tar.gz
/etc/init.d/cron stop
/etc/init.d/postfix stop
/etc/init.d/apache2 stop
cd /opt/otrs/
su - otrs
bin/Cron.sh stop
bin/otrs.Daemon.pl stop
logout
mysqldump -p otrs > otrsdbbackup.sql
cd /opt
mv otrs otrs-old
tar -xzf otrs-5.0.2.tar.gz 
mv otrs-5.0.2 otrs
cp /opt/otrs-old/Kernel/Config.pm /opt/otrs/Kernel/
cp /opt/otrs-old/Kernel/Config/GenericAgent.pm /opt/otrs/Kernel/Config/
cp /opt/otrs-old/Kernel/Config/Files/ZZZAuto.pm /opt/otrs/Kernel/Config/Files/
cp /opt/otrs-old/var/log/TicketCounter.log /opt/otrs/var/log/
cd /opt/otrs/var/cron
for foo in *.dist; do cp $foo `basename $foo .dist`; done
cd /opt/otrs/
bin/otrs.SetPermissions.pl --web-group=www-data
su - otrs
bin/otrs.Console.pl Maint::Database::Check
bin/otrs.Console.pl Maint::Config::Rebuild
bin/otrs.Console.pl Maint::Cache::Delete
logout
/etc/init.d/apache2 start
/etc/init.d/postfix start
/etc/init.d/cron start
su - otrs
bin/otrs.Daemon.pl start
bin/Cron.sh start
logout

und dann noch im backend unter “admin” -> “paket-verwaltung” die installierten pakete in einer neuen bzw kompatiblen version installieren.

…so wie es fuer meine installation funktioniert(e). in diesem falle von 4.0.13 auf 5.0.1.

zu hilfe genommen habe ich:

http://otrs.github.io/doc/manual/admin/5.0/en/html/upgrading.html
https://ww.sd.vc/wp/2014/12/10/otrs-4-patchlevel-update/

eine art braindump fuers naechste update 😉

apt-get install -y libmime-base64-urlsafe-perl libauthen-sasl-perl libxml-libxml-perl libxml-libxslt-perl
cd /opt
wget http://ftp.otrs.org/pub/otrs/otrs-5.0.1.tar.gz
/etc/init.d/cron stop
/etc/init.d/postfix stop
/etc/init.d/apache2 stop
cd /opt/otrs/
su - otrs
bin/Cron.sh stop
bin/otrs.Scheduler.pl -a stop
logout
mysqldump -p otrs > otrsdbbackup.sql
cd /opt
mv otrs otrs-old
tar -xzf otrs-5.0.1.tar.gz 
mv otrs-5.0.1 otrs
cp /opt/otrs-old/Kernel/Config.pm /opt/otrs/Kernel/
cp /opt/otrs-old/Kernel/Config/GenericAgent.pm /opt/otrs/Kernel/Config/
cp /opt/otrs-old/Kernel/Config/Files/ZZZAuto.pm /opt/otrs/Kernel/Config/Files/
cp /opt/otrs-old/var/log/TicketCounter.log /opt/otrs/var/log/
cd /opt/otrs/var/cron
for foo in *.dist; do cp $foo `basename $foo .dist`; done
cd /opt/otrs/
bin/otrs.SetPermissions.pl --web-group=www-data
/opt/otrs/bin/otrs.CheckModules.pl
cat scripts/DBUpdate-to-5.mysql.sql | mysql -p -f -u root otrs
su - otrs
bin/otrs.Console.pl Maint::Database::Check
scripts/DBUpdate-to-5.pl
cd /opt/otrs/
bin/otrs.Console.pl Maint::Config::Rebuild
bin/otrs.Console.pl Maint::Cache::Delete
logout
/etc/init.d/apache2 start
/etc/init.d/postfix start
/etc/init.d/cron start
su - otrs
/opt/otrs/bin/otrs.Daemon.pl start
/opt/otrs/bin/Cron.sh start
logout

und dann noch im backend unter “admin” -> “paket-verwaltung” die installierten pakete in einer neuen bzw kompatiblen version installieren.

notiz fuer mich selbst… ultrakurzanleitung. bitte nicht verwenden, wenn man sich nicht sicher ist, was man da macht. datenverlust droht!

fsck -f /dev/vg0/hostname-disk
resize2fs /dev/vg0/hostname-disk 8G
lvreduce --size 8G /dev/vg0/hostname-disk