Aus der Tiefe
   


About
Aus der Tiefe, Meldungen des Rechenzentrums in der Cauerstrasse 11

Matthias Bauer und Martin Bayer problems@math.fau.de

Subscribe
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Flavours
There's more than one way to view this weblog; try these flavours on for size.

  • index
  • circa 1993
  • RSS
  • Links

  • Shoestring FoundationMiscellaneous byproducts

  •        
    Thu, 16 Jul 2020

    Thursday, July 16, 2020 15:38:48


    	Den Mailserver auf neue Hardware und neues Ubuntu gebracht.
    	   1. postfix/dovecot angehalten
    	   2. /var/mail weggesichert
    	   3. /var/mail auf neuer maschine ge-rsync-t
    	   4. Zertifikate, keys, kerberos keytabs von altem auf neuen server gezogen
    	   5. Weil apache2 -> hiawatha umstellung, keys+cert+chain entsprechend umgewandelt
    	   6. auf beiden maschinen /etc/network/interfaces mit neuen addrs versehen
    	   7. reboots
    	   8. hostnames umgestellt und in diversen configfiles geaendert
    	   9. postfix/dovecot/webmailer restart
    	  10. Rewrite rules in hiawatha reingebaut, damit der webmailer unter allen beliebten URLs erreichbar ist
    	  11. Firewall rules auf dem neuen Mailer angepasst
    	  12. Zuruecklehnen und den einprasselnden SMTP/IMAP/Submission Verbindungen zuschaun.
    	 Und weil ja nie was glattgehen kann:
    	  13. Feststellen, dass ein paar ConfigVersehen aus der Gruenderzeit dieses Deparments uns beissen koennen:
    	    Bei der LDAP+Kerberos Einfuehrung gabs Verwirrung, weil in LDAP (genauer in der posixAccount Class)
    	    die "uid" nicht die POSIX uid ist (waer ja auch zu einfach). Die "uid" ist — nicht die unique ID, weil das
    	    ist ja der Distinguished Name — der login-name, die POSIX uid heisst "uidNumber" (logisch). Und so
    	    kam es, dass wir Accounts angelegt hatten, die eine uid als uid hatten. Dass man sich dann nicht einloggen
    	    kann, weil die POSIX-uid als name im kerberos benutzt wird statt dem usernamen, fiel schnell auf.
    	    Statt die rauszuloeschen, haben wir damals einfach noch eine uid drangepappt, naemlich den username.
    	    Und das ging ganz wunderbar, weil nslcd+pam_krb5 irgendwie die nicht-numerische uid genommen haben.
    	    Das ist mit dem neuen sssd genau andersrum, der nimmt lieber Zahlen, wenn vorhanden. Und die zehnoderso
    	    User, die damals unbewusst LDOPfer des Irrtums waren, kamen nicht mehr an ihre Mails. Dreck.
    	    Mein altes fixusername Skript, das mit ldap_modify und 
    		changetype: modify
    	        replace: uid
    	        uid: $newname
    	    funktioniert hat, tut warumauchimmer nicht, wenn es zwei uids fuer den DName gibt. Loesung ist
    	        changetype: modrdn
    	        newrdn: uid=$newuid
    	        deleteoldrdn: 1
    	    Mit 
    		for i in `seq 0 9`; do ldapsearch "(uid=$i*)"; done
    	    durchgeschaut und alle korrigiert.
    
    

    [/bauerm] permanent link