Tag: linux

wenn man auf bei einem gut frequentierten postfix “mal schnell was debuggen” muss, dann will man nicht laenger als noetig das debugging angeschaltet haben. das logfilze explodiert sonst sprichwoertlich.

sondern… mal will vielleicht nur die kommunikation mit einem bestimmten client/server debuggen. dann macht man das so:

postconf -e "debug_peer_list = ip.ip.ip.ip" && postfix reload

…dann verschickt man seine testmail und schaltet das anschliessend wieder ab:

postconf -e "debug_peer_list =" && postfix reload

mir kam schon ein paar mal ein postfix unter, der komische sachen mit email headern gemacht hat. da stand z.b. sowas drin:

To: “irgendwas@domain.tld”@mein.mailserver.tld

das kann z.b. auftreten, wenn man amavis als contentfilter in der master.cf eingebunden hat. dann sollte man in der master.cf beim eintrag des smtp-servers von amavis folgende option mitgeben:

-o local_header_rewrite_clients=

ursache dafuer ist der standardwert “local_header_rewrite_clients=permit_inet_interfaces”, der zutrifft, wenn die mails von amavis auf localhost:10025 wieder rein kommen.

ohne gross darauf einzugehen warum, weshalb… einfach als gedaechtnisstuerze fuer mich.

wenn man unter debian wheezy diese beiden pakete installiert hat:

openjdk-6-jdk
openjdk-7-jre

…dann ist standardmaessig java 6 die default version. ich weiss nicht, wie man das normalerweise und richtig macht. hier musste es schnell gehen und mir ist nur eingefallen:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-7-openjdk-amd64/bin/java 1100

und so siehts dann aus, wenn man “update-alternatives –config java” aufruft:

weiter gehts mit den ciphers, die java standardmaessig zur verfuegung stellt. manche sachen wie z.b. SSLv2, SSLv3, RC4 und irgendwelche “weak ciphers” will man ja nicht haben. um das abzustellen, fuegt man diese zeile (eine zeile!) in die datei /etc/java-7-openjdk/security/java.security ein bzw editiert diese, sofern schon vorhanden:

jdk.tls.disabledAlgorithms=SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DH_DSS_WITH_DES_CBC_SHA, SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DH_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA, SSL_FORTEZZA_DMS_WITH_NULL_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_IDEA_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, TLS_DHE_PSK_WITH_RC4_128_SHA, TLS_ECDH_anon_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_PSK_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_RC4_128_SHA, TLS_PSK_WITH_RC4_128_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, TLS_RSA_PSK_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

und da man auch keine schluessel kleiner 1024 akzeptieren will, auch noch diese zeile:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

openjdk hats irgendwie auch nicht so mit der validierung von remote zertifikaten, weshalb das mit dem TLS dialback nicht funktioniert. deshalb muss man in der datei /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/java.security auch noch diese zeile auskommentieren: (mit einem # anfang versehen)

security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

und dann noch die sache mit dem importieren eines von einer CA signierten zertifikates… dazu brauchts:

– das zertifikat selbst (jabber-signed.pem)
– den key (jabber-private.pem)
– die “certificate chain” der CA auch im PEM format (hier chain1.pem und chain2.pem)
– ImportKey.java von agentbob

los gehts…

in der datei “ImportKey.java” von agentbob diese zeilen den eigenen gegebenheiten anpassen:

[..]
String keypass = "changeit";
[..]
String defaultalias = "private-key";
[..]
String keystorename = "keystore";

und dann die ImportKey.java mit diesem befehl kompilieren:

javac ImportKey.java

und so fortfahren:

/etc/init.d/openfire stop
cd /etc/openfire/security
cp truststore truststore.org
cp keystore keystore.org
keytool -importcert -alias chain1 -keystore truststore -file chain1.pem
keytool -importcert -alias chain2 -keystore truststore -file chain2.pem
openssl pkcs8 -topk8 -nocrypt -in jabber-private.pem -inform PEM -out jabber-private.der -outform DER
openssl x509 -in jabber-signed.pem -inform PEM -out jabber-signed.der -outform DER
java ImportKey jabber-private.der jabber-signed.der
/etc/init.d/openfire start

in der admin webgui steht bei dem key nun “pending verification”… stimmt garnicht. hab ich einfach ignoriert. genauso wird angezeigt.. “One or more certificates are missing. Click here to generate self-signed certificates” ..stimmt auch nicht. hab ich auch einfach ignoriert.

ich denke, das wars. mit dem “IM Observatory” auf xmpp.net kann man anschliessend testen, ob nun alles so ist, wie man sich das erhofft… voila:

wenn sich die url bzw. domain einer webseite aendern, aber weiterhin auf dem alten webpraesenz etwas z.b. in einem unterordner erreichbar sein soll, muss man diesen unterordner quasi “excluden”. mit der rewrite rule in der .htaccess geht das so:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.domain-alt\.tld$
RewriteCond %{REQUEST_URI} !\/ordner\/.*$    [NC]
RewriteRule ^(.*)$ http://www.domain-neu.tld/$1 [L,R=301]

irgendwie bin ich in sachen hardware nicht mehr up to date. ein nich tmehr ganz neues, schnuckeliges supermicro 1he gehaeuse mit einem brauchbaren dual core xeon stand noch rum. hmm… zwei grosse platten rein und daraus einen backup server gebaut. gesagt getan… aber waere zu schoen, wenn mal alles auf anhieb klappen wuerde.

erstmal musste ich lernen, dass aeltere bios’se mit 4TB platten nicht koennen. knapp 2TB wurden vom bios erkannt. aber nach kurzer recherche war klar, dass man nur die partition zum booten entsprechend klein halten und am anfang platzieren muss. der rest der grossen platte wird dann vom betriebssystem erkannt. (zumindest bei einem linux)

lektion zwei war, dass bei der nutzung von grossen platten, gpt und grub am anfang der platte eine kleine partition vom typ EF02 (BIOS boot partition) vorhanden sein muss. irgendwas soll das mit uefi zu tun haben, was ich aber garnicht habe. verstanden habe ich das alles nicht… aber egal. einfach machen.

die partitionierung bzw das anlegen dieser einen partition musste ich mit einer knoppix cd machen, da auf der debian netinst keine passenden programme drauf sind, um partition auf einer platte mit GPT zu erstellen. (ja, mit sicherheit ist da sowas drauf, aber ich hab nix mir bekanntes gefunden.)
also husch auf beiden platten identische partitionen vom typ EF02 angelegt. dann mit der debian netinst cd die restlichen platten partitioniert, MD devices angelegt, konfiguriert und installiert. und dann geschahen komische dinge…. nach der installation wollte die kiste nicht booten. da kam so ein kauderwelsch:

mdadm: Devices UUID-7a140585:a601a93a:a6265560:0120df65 and
UUID-7a140585:a601a93a:a6265560:0120df65 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/c5bf7b81-f808-4bf7-b554-f7bc2d6c0479 does not exist
Dropping to shell!

die loesung dazu gabs dann im debianforum. aus der datei /etc/mdadm/mdadm.conf muss man den doppelten eintrag raus loeschen. welcher der richtige ist… keine ahnung. bei mir wars praktischerweise der erste 😉

mit “exit” kommt man dann aus der busybox raus und die kiste startet. damits beim naechsten boot noch klappt, noch das ausfuehren:

update-initramfs -vu

ich hab dann gleich noch den grub auch auf die zweite platte installiert. fuer den fall, dass /dev/sda ausfaellt und man von /dev/sdb booten muss.

dpkg-reconfigure -plow grub-pc 

alle modernen betriebssysteme benutzen den “linefeed character (LF)” um einen zeilunumbruch in einer ascii datei zu machen. nur windows nicht. die benutzen einen “carriage return followed by a linefeed (CRLF)”. wenn man nun irgendwelche textfiles auf z.b. einem linux system generiert und auf einem windows rechner anschauen will, muss man nachhelfen. die von windows mitgebrachten anzeigeprogramme hauen sonst alles in eine zeile…

sed -i 's/$/\r/' datei.txt

that’s all.

immer wieder gebraucht und jedesmal auf der suche, wie das geht… nun stehts hier.

auf einem debian system braucht man dazu diese beiden pakete.. falls sie nicht sowieso schon drauf sind:

mailx
sharutils

und so gehts:

(echo "bodytext"; uuencode /tmp/inputdatei.txt \
dateinameindermail.txt) | mail -s "betreff" -a \
"From: absender@domain.tld" "empfaenger@domain.tld"                        

(das ist eine zeile!)

… nicht nur wegen der 3,3 jahre uptime, sondern auch weil der server selbst und das betriebssystem in die jahre gekommen ist. ungefaehr acht jahre hat das ding nun bei mir auf dem buckel. und den habe ich damals schon gebraucht erstanden.

~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.00GHz
stepping : 7
cpu MHz : 1992.796
cache size : 128 KB

damit ist nix mehr zu gewinnen. und mit dem strom kann man heutzutage mit aktueller hardware mehr anstellen 😉

naja eigentlich nicht vom contao checker, sondern von mir… er wollte seine installation updaten und per ftp dauert das dank mieser internetverbindung immer so lange. also hab ich das ganze mal auf der kommandozeile gemacht. geht wesentlich schneller 😉

und ein kleiner braindump fuer mich fuers naechste mal (damits noch schneller geht!):

# erstmal backup machen
cd /var/www/sites/kundexy
mysqldump -p -h dbserver database > 201412211004.sql
tar -czvf 201412211004.tar.gz verzeichniswebseite/
# dann update laden und installieren
cd verzeichniswebseite
curl -L  -o core-3.2.16.tar.gz https://codeload.github.com/contao/core/tar.gz/3.2.16
tar --strip-components=1 -zxvf core-3.2.16.tar.gz
chown user.group ../verzeichniswebseite/ -R
# und wenn alles danach noch funktioniert, das backup loeschen:
rm core-3.2.16.tar.gz
rm ../201412211004.sql
rm ../201412211004.tar.gz
# feddich!

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

zu hilfe genommen habe ich:

https://otrs.github.io/doc/manual/admin/stable/en/html/upgrading.html
http://otrs.github.io/doc/manual/admin/4.0/de/html/manual-installation-of-otrs.html

eine art braindump fuers naechste update 😉

/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 -uuser -ppasswort -hhost otrs > otrsdbbackup.sql
cd /opt
wget http://ftp.otrs.org/pub/otrs/otrs-4.0.2.tar.gz
mv otrs otrs-4.0.1
tar -xzf otrs-4.0.2.tar.gz
mv otrs-4.0.2 otrs
cp /opt/otrs-4.0.1/Kernel/Config.pm /opt/otrs/Kernel/
cp /opt/otrs-4.0.1/Kernel/Config/GenericAgent.pm /opt/otrs/Kernel/Config/
cp /opt/otrs-4.0.1/Kernel/Config/Files/ZZZAuto.pm /opt/otrs/Kernel/Config/Files/
cd /opt/otrs/var/cron
for foo in *.dist; do cp $foo `basename $foo .dist`; done
cp /opt/otrs-4.0.1/var/cron/postmaster_mailbox /opt/otrs/var/cron/
cd /opt/otrs/
bin/otrs.SetPermissions.pl --web-group=www-data
su - otrs
bin/otrs.RebuildConfig.pl
bin/otrs.DeleteCache.pl
logout
/etc/init.d/apache2 start
/etc/init.d/postfix start
/etc/init.d/cron start
su - otrs
bin/Cron.sh start
bin/otrs.Scheduler.pl -a start
logout

und dann noch im backend unter “admin” -> “paket-verwaltung” die pakete erneut installieren