-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 40 von 49)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

AMaViS Performance-Tuning

22. September 2012 / / Keine Kommentare

Ich beobachte in der letzten Zeit immer mal wieder dass E-Mails im AMaViS lange hängen bleiben…. Viel Zeit scheint dabei für die Festplatte bzw. die Schreib-/Lesezugriffe drauf zu gehen. Die E-Mail wird von AMaViS angenommen, in dessen tmp Verzeichnis geschrieben. Dann noch ein paar mal gelesen um alle Tests zu machen, ausgepackt usw. usw… Um dieses etwas einzugrenzen habe ich mich gedacht, warum nicht eine RAM Disk für AMaViS oder besser für dessen Temp?

Auf einer gängigen Debian Kiste findet sich dieses Verzeichnis hier:

/var/lib/amavis/tmp

 Damit dieses Verzeichnis nicht mehr auf der Festplatte herum-gewürfelt wird, sondern sich nur noch im Arbeitsspeicher des Servers befinden (der ist ja viel schneller als so ne olle HDD) trägt man folgendes in seine /etc/fstab ein:

/dev/shm    /var/lib/amavis/tmp    tmpfs    defaults,size=256m,mode=750,uid=109,gid=113    0 0

 Man sollte nur darauf achten, dass uid und gid die des lokalen amavis sind. Sonst darf am Ende AMaViS nicht mehr in ein eigenes Temp schreiben 😛 Es soll bessere Wege die ID zu finden, ich mache es schnell und einfach mit:

$ cat /etc/passwd|grep amavis
amavis:x:109:113:AMaViS system user,,,:/var/lib/amavis:/bin/sh

109 ist dabei die User-ID
113 ist die Group-ID

 Das neue AMaViS-tmp ist damit 256MB gross. Für die Grösse gibt es eine „Faustformel“… Diese macht nicht für jeden Sinn! Man würde mit dieser Formel zwar _fast_ nie in die Gefahr eines zu kleinen AMaViS-temps laufen, nur verbrennt man so seinen RAM. Try and Error ist hier eher mein Vorschlag. Denn sollte AMaViS wirklich mal keinen Platz mehr haben, wird die E-Mail mit einem temporären Fehler abgewiesen. Der einliefernde Mailserver wird daher versuchen die E-Mail ein paar Minuten später noch einmal zuzustellen. Damit sollte keine E-Mail verloren gehen. Als Admin behält man nach so einer Änderung einfach seinen Server im Auge und erhöht bzw. reduziert den Wert/die Grösse… Fertig 🙂

Die RAM-Disk gibt AMaViS einen extremen Boost und steigert so dessen Performance enorm. Ich finde es kommt selten vor dass man so einfach ein so krasses Performance-Tuning hin bekommt. Nun laufen die E-Mails also schneller durch AMaViS und mein Postfix muss nicht mehr so lange auf die Filterung warten. WOOOOHOOOOO

Linux und die UUID

17. September 2012 / / Keine Kommentare

Ich bin inzwischen ja von ZFS schon sehr verwöhnt… Vor allem was so Dinge angeht sich Kombinationen aus Laufwerk, Partition, Mountpunkt und SATA-Port zu merken. Man denkt einfach nicht mehr darüber nach 🙁 Heute bin ich damit mal wieder auf die Nase gefallen. Ok ok…. Natürlich kann man zur Konfiguration auch einfach die UUID nutzen, diese ist dann eindeutig und man kann ähnlich wie bei ZFS die ganzen Zusammenhänge „vergessen“….. Ich finde die UUID-Geschichte aber anstrengend. Diese viel zu lange Nummer zu tippen geht überhaupt nicht, sich diese erst in Konfigurationsfiles zu schieben und dann…. bäääähhhh. Dann kann ich mir die Nummer auch nur wieder schlecht merken.

Wie auch immer. Der Ansatz ist gut und wenn es Konfiguriert ist, geht es ja auch. Um mir nicht noch ein Komando mehr merken zu müssen friemel ich die Zuordnung UUID ==> Devicename immer wie folgt heraus:

ls -Al /dev/disk/by-uuid/
insgesamt 0
lrwxrwxrwx 1 root root 10 17. Sep 11:26 0e6894c5-1dfd-4fcb-8cc4-12290c28c3dc -> ../../sdb3
lrwxrwxrwx 1 root root 10 17. Sep 11:26 11cc385c-7fcc-4b87-88b9-ebe05af67df8 -> ../../sda1
lrwxrwxrwx 1 root root 10 17. Sep 11:26 2fc86b49-ad36-4755-bd72-aba0ec54f2e4 -> ../../sdb2
lrwxrwxrwx 1 root root 10 17. Sep 11:26 ca266482-0623-43a1-8741-70f8de485023 -> ../../sdb1

Jemand eine bessere Idee? In diesem Sinne….

Unser RIPE ist bald wirklich alle: Einblick in die Erschöpfung der IPv4-Adressen

11. September 2012 / / Keine Kommentare

RIPE ist in Sachen IPv4 Adressen nun soweit leer dass sie nun auf ein „erweitertes“ Vergabeverfahren wechseln. Soll bedeuten dass nun ganz super streng (bla bla bla) kontrolliert wird warum und wo die Adresse hingeht und ob die auch wirklich gebraucht wird…..

Wie auch immer! Damit man sich besonders gut anschauen kann was noch übrig ist gibt es von den Jungs selbst eine kleine Grafik (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph).

Dass ich ein großer Freund davon bin, mal endlich mit IPv6 aus dem Arsch zu kommen, muss ich ja keinem mehr erzählen. Wenn ich mir andere Hochrechnungen anschaue (http://www.potaroo.net/tools/ipv4/index.html) dann haben wir aktuelle noch bis zum 24.09.2012 (das ändert sich noch mal) IPv4 Adressen 😛

Ja ja… IPv4 ist ab dem Tag nicht tot (Dualstack für die nächsten Jahre..) und unsere Provider und Hoster haben auch noch Reserven. Zusätzlich kann man ab dem Moment beginnen seine IPv4 Adressen zu verkaufen *lach*…..  AAAABBBER, warum der ganze Stress? Warum nicht einfach mal mit IPv6 beschäftigen? Nein nein, ich meine wirklich beschäftigen, nicht nur so tun als ob 😛

Nostalgie Pizzeria

1. September 2012 / / Keine Kommentare

Ein trauriger Tag *schnief* denn ich muss mich wohl von meiner lieblings Pommesbude trennen. Nostalgie Pizzeria in Sprockhövel…..  Die Gerichte sind nicht wirklich schlecht aber Preis/Leistung passt aus meiner Sicht einfach nicht mehr zusammen. Die Qualität ist irgendwie in den letzten 1,5 Jahren immer immer immer weiter abgesackt. Langsam aber stetig, so zumindest der eindeutige Eindruck von mir und meiner Familie.

Nun ist es dann wohl so weit, lange habe ich es herausgezögert 🙁 jetzt muss ich mir denn noch einen neuen Lieferservice suchen. Die letzte Bestellung beendete eindeutig unser „Verhältnis“. Bye bye Restaurant Pizzeria Nostalgie.

 

Telekommailserver verschärfte Bedingungen der Mailannahme

22. Juni 2012 / / Keine Kommentare

Na also, nun hat die Telekom die Sicherheitsrichtlinien ihrer E-Mail Server so angepasst dass helo, hostname und R-DNS zusammenpassen müssen. Sonst gibt es diese Meldung:

A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)

So gefällt mir das! Meine Kiste macht dieses ja schon länger so und ich bekomme immer mal wieder die Info, man könne mir keine E-Mail schicken. Mein Mailserver sei wohl kaputt, er sage immer:

550 5.7.1 Client host rejected: cannot find your hostname….

Wenn ich dann erkläre um was es geht bekomme ich immer mal wieder den Vorwurf da zu –genau- zu sein. Da jetzt noch ein weiteres großes Unternehmen genau so verfährt werden sich wohl noch mehr Mailserver „Administratoren“ um dieses Problem kümmern müssen. Lustig finde ich ja dass die Telekom direkt eine E-Mail Adresse angegeben hat tosa@rx.t-online.de, was da wohl abgehen muss 🙂

 

http://www.kernel-error.de/postfix-spam-und-virenabwehr-durch-helo

 

 

 

R-DNS geht nicht

14. Juni 2012 / / Keine Kommentare

Na toll… Unsere RIPE hat gerade echte Probleme mit ihrem DNS System 😛 Da brennt wohl gerade der Busch:

RIPE schreibt folgendes an die RIPE-Members-Mailingliste:

„It seems that our DNS provisioning system has developed a major fault, with the result that it is unable to generate DNS zonelets for the other RIRs.
This required a complete bootstrap of the system, and unfortunately, this may take a few hours, during which no DNS provisioning will happen.
We are aware of the problems and our engineers in the DNS department are working hard to fix the issue as soon as possible. Unfortunately at the moment we are not able to provide an estimated time of the repair yet.
An announcement will be sent out to all the Working Group Mailing list with a detailed explanation of the issue and a summary of what is actually being done for fixing it.
Please accept our apologies for the inconvenience and the troubles that the issue may have caused to you.
Regards,
Jarek“

Mehr hier: http://www.ripe.net/internet-coordination/news/announcements/update-regarding-the-reverse-dns-services-issues

Die Liste ist aber nicht wirklich aktuell….

Hier auch noch mehr: http://www.ripe.net/lir-services/service-announcements

Mehr als nur A-Records

27. Mai 2012 / / Keine Kommentare

Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:

GPG im DNS: http://www.kernel-error.de/dnssec/gpg-im-dns

SSH-Key im DNS: http://www.kernel-error.de/dnssec/ssh-key-im-dns

Hinzufügen der GPG Keys zum DNS

27. Mai 2012 / / Keine Kommentare

GnuPG bietet seit längerem verschiedene Möglichkeiten DNS Server nach gpg/pgp Schlüsseln zu fragen. Die aus meiner Sicht einfachste und schnellste ist PKA.

Kann der GPG Client den Schlüssel selbstständig aus dem Internet laden muss ich mich nicht mehr darum kümmern meinen aktuellen öffentlichen Schlüssel auf allen möglichen Key-Servern zu verteilen. Kommt der Schlüssel oder die Information zum Schlüssel und dessen Fingerprint noch von dem DNS Server, welcher für die Domain/Zone zuständig ist, kann man sich noch etwas sicherer sein. Ist diese Zone dann noch per DNSsec (http://www.kernel-error.de/dnssec) geschützt… Ja dann kann man noch etwas sicherer sein! 100%tige Sicherheit gibt es nicht, ich kann mich nur den 100% annähern. Um so besser mir dieses gelingt um so sicher kann ich mir sein 🙂

Wie geht es nun? Recht einfach. Ich exportiere meinen public key und sorge dafür das http clients (https ist nicht wirklich nötig, da der Schlüssel am Ende eh mit dem Fingerprint verglichen wird) diesen herunterladen können. Dann erstelle ich einen Fingerprint meines Schlüssels und veröffentliche beide Informationen zusammen mit der/den E-Mail Adressen in der DNS Zone.

OK los geht es. Zuerst besorge ich mir die Key-ID meines GPG-Keys:

$ gpg --list-keys kernel-error@kernel-error.com

Nun exportiere ich den öffentlichen Teil meines GPG-Keys, den public Key:

$ gpg --export --armor 0F9874D8 > kernel-error.asc

Jetzt brauche ich noch den Fingerprint meines GPG-Keys:

$ gpg --list-keys --fingerprint 0F9874D8

Nun beginne ich die records für meine DNS Zonen zu bauen. Diese sehen wie folgt aus:

E-Mail Adresse (das @ wird zu ._) gefolgt vom record Type TXT sowie dem Fingerprint ohne Leerzeichen und der HTTP-Adresse des öffentlichen Schlüssels.

Für mich schaut es so aus:

Zone kernel-error.com:

kernel-error._pka.kernel-error.com.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Zone kernel-error.de:

kernel._pka.jabber.kernel-error.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"
kernel-error._pka.kernel-error.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Zone vandemeer.de:

sebastian._pka.vandemeer.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Ob sich die records abrufen lassen teste ich mit dig:

dig +short kernel-error._pka.kernel-error.com. TXT

Klappt dieses probiere ich ob gpg auch alles findet. Da ich den Schlüssel natürlich bereits in meinem Keyring habe, sage ich gpg dass es einen neuen Keyring unter /tmp/ anlegen soll. In diesen wird dann auch der Public Key importiert, wenn alles funktioniert 🙂 Das echo „foo“ | ist nur damit gpg auch Daten hat die es anfassen soll!

Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten

Diesen Schlüssel trotzdem benutzen? (j/N) j
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)

hQIMAyLQ0wrCELyPAQ//SaagWN6N57qIN1s0IksGwbXpchBTTW4FWZVotKUeHeHv
6LQ2abOL3ulRbzIHOmYINT3CUJ3Pf0DmFm44UqXP0Ay/R0PpANNqumshP8J+0aBY
YyhImPEk4s6qK8rJqD0+0F5sWrX7A2bPbmBHmp6BDQSpIUKxTXFTChJ0Hx7n/ntn
X3iLIpl3NYzvWd78Q+7lFcH9TDL+tLb655lwbZ4HcaQOT6NAkHAL76Td8CDQdbUM
Iu7UcZrpVebAaT7dL0HcifpNy+Vfo3xzq7b/MQsHxYASgafwtuOLCJr7Mi1bJqsk
eLZgxtLsflhgnkK/4Yj/zz7TosvUKb6ZemMxok6B95tmIMmBzJt9QPtBhuF6Uhgc
Vr6E6YSM3dKOy3e2N2YEYS/eXUk68S/2B+PtSBRxMuwMB9qIfLxqZPDrMgSoSOOz
7IaBqAy+HZ7JQdYDBg+6uLrf17+hjiX9g3X/sJB002lTqEJ5aIz+fe1QBXwqM97b
7hcOQCbEm1XQOFJmJWPsgROvpQhMZvd8ylLSIKtIKHqWgn0CkobABQ5Y9HJVkpO2
+DID8yT4Iy/be/YfCzU56i2AnswduZpK3bc2DLEPORVRp6PloNOmNhTXtf6IsN1X
mZfGr3sycFq7XNY9M5nha6Jco2ZdBSgebcKNZlkPF7f1GMDfnAAJgwUcX0QMSp7S
PwFvh2D0NqPcl1Rb7ManjL5tpR0NCjnxVEPNRv0j+2Ejr7LGKH/yqZVbnr+eiSRX
FPSvDQJVgT65sPIyn0k6tg==
=k7cd
-----END PGP MESSAGE-----

Tja, damit sollte wohl nun jeder meinen GPG-Key über meinen per DNSsec geschützten DNS Server besorgen können.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑