Debian Squeeze Server, Raid1 und Mailserver Fragen/Probleme

[RQj7]

Hallo Leute

Ich hab mal wieder ein (paar) Problem(-chen) und würde mich freuen, hier bei euch, ein bisschen Hilfe zu finden. Vorweg: Klar hab ich gegoogelt und auch die Boardsuche verwendet. Aber so wirklich fündig bin ich auch nicht geworden. Bitte nicht gleich agressiv werden, wenn ich etwas übersehen habe, Das war nicht mit Absicht. Für neue Vorschläge, Erfahrungen u.Ä. bin ich offen, also bitte einfach sagen wenn Ihr noch was wissen wollt, okay?

Systemdetails:
- Hostinganbieter: 1und1, Tarif Server 2012 XL 6 Core
- Hardware und Partitionierung siehe hardware.txt im Anhang.
- Aufgaben: Web- Mail- FTP- Virtualisierungsserver
- Feste, öffentliche IP und Domain.
- Zur verwaltung ist Webmin installiert, jedoch noch nicht wirklich genutzt. (eher die ssh-konsole)

Nun zu den Problemchen...

Baustelle 1:
Das erste Problem habe ich mit dem werksstandardseitigen (Hardware?) Raid 1. Partitionierung und Festplatten im Anhang (hardware.txt). Wie kann ich diese Raid 1 Volumes mounten, bzw überhaupt nutzen?

$ mount /dev/md0 /mnt/
        mount: special device /dev/md0 does not exist


bzw.

$ mount /dev/sda3 /mnt/
       mount: unknown filesystem type 'linux_raid_member'

Baustelle 2:
Bei diesem Tarif wird Rechenzentrumsseitig eine "Externe Cisco-basierte IP-Firewall" verwendet. Was meint Ihr, reicht die aus oder sollte ich noch Software Firewalls oder Iptables verwenden? Wenn ja, wie konfiguriere ich das?


Baustelle 3: - wohl eher die Größte...
Ich versuche seit geraumer Zeit einen Postfix- mit Dovecot-Server zu konfigurieren, so dass er funktioniert. Aber ich komme einfach nicht weiter... Dieses Turoial habe ich verwendet und bin im Moment bei der Roundcube-config stehen geblieben, genauer: bei dem Test des SMTP-Servers und des IMAP-Zugriffs. Die Konfigurationsdateien habe ich im Anhang unter dovecot.txt und postfix.txt. Ich bitte um Hilfe.


Vielen Dank im voraus. Wenn Ihr noch etwas wissen wollt/müsst, dann sagt es bitte, ich beiße nicht!


MfG RQj7

 

[andy_0]

Ich kann dir in den spezifischen Problemen leider wenig weiterhelfen.

Mit Postfix und Dovecot habe ich mich auch ewig rumgeschlagen. Am Ende lief es, aber es ist schon aufwändig. Ich habe übrigens die selbe Anleitung gehabt . Mittlerweile habe ich auf ein neuen Server aufgerüstet und werde dort demnächst Kolab installieren. Ich würde dir ähnliches anraten. Du hast dann nicht nur mehr Mail und Groupware Features, sondern ein "Installer" und eine gute Anleitung. Alternativ gibt es z.B. OpenXchange, Zarafa, Zimbra und Co., wobei Kolab IMHO die bessere Lösung ist. Kolab unterstützt u.a. Active Sync, während OX zwar ein super Interface und Usability hat, aber Active Sync nicht in der kostenfreien Version unterstützt wird.

Meine Erfahrung mit Postifx und der Anleitung ist erst einmal: geht was nicht, hat man was übersehen. Die Konnektivität mit Postifx testet man via Telnet. Meine Empfehlung wäre erst einmal die ganzen SASL Notwendigkeit bzw. Unterstützung in Postfix abzuschalten. Postfix selber läuft unabhängig von Dovecot, Roundcube und anderen Anwendungen.

Unter Linux verwendet man eigentlich keine Firewall. Man kann schon, ist aber nicht notwendig. Man installiert einfach keine Anwendung die man nicht braucht und die die man installiert sichert man ab. Solch eine "Firewall" wäre ja eh nur ein Portblocker, aber wozu Ports blocken die keine von deinen Anwendung verwendet?

Hast du dir einen extra Benutzer mit sudo Rechten angelegt? Root Login für SSH deaktiviert? Eine "must have" ist fail2ban. Das überwacht die Logs und tut nach x fehlerhaften Loginversuchen (FTP, SSH, ...) den Login für die IP für y Minuten sperren. Jede Anwendung sollte mit einem eigenen Nutzer laufen, welcher keine Loginmöglichkeit (Shell auf: /bin/false) besitzt. Dateien mit Zugriffsdaten z.B. in den SQL Server sollten nur dem Benutzer für die Anwendung zugänglich sein (also keine 666 Rechte sondern nur 600 oder ähnlich).

 

[RQj7]

@andy_0:

Ersteinmal vielen Dank für diene schnelle Antwort.

Kolab, bzw. die anderen werde ich mir demnächst anschauen. Vielen dank dafür!

Nja das problem ist eben, dass ich selbst mit telnet keinen Login schaffe und ich weiß halt auch absolut nicht wieso... Aber wenn es dir ähnlich ergang dann werde ich doch mal Kolab probiern, wenn ich die Zeit dazu finde

Ja das stimmt und klar ist mir das eigentlich auch, aber ich bin grade nicht selber drauf gekommen...

Nein das nicht, aber einen anderen Benutzer über den ich mich dann mit su als root einlogge... Rootlogin selbst ist deaktiviert, außerdem hab ich den SSH-port geändert. Reicht das oder sollte ich fail2ban trotzdem nutzen?

Okay, das habe ich schonmal gehört - muss ich "bloß" noch umsetzen... Aber trotdzem DANKE!




@all:

Wenn mir jetzt noch jemand das Problem mit dem RAID 1 lösen kann, bzw einen Lösungsansatz für mich hätte?

 

[andy_0]

Installiere fail2ban. Ein Portscan ist wirklich kein großes Ding und schon Brute Forcen die dir dein Login. Dauert zwar so lange, dass es wohl nichts bringt, aber sicher ist sicher. Ich persönlich hab den Port für SSH gar nicht verschoben. Sehe ich in etwa so sinnvoll wie die SSID im WLAN ausschalten . Fail2ban funktioniert außerdem auch mit "allem" was eine Logfile hat - wenn es denn dafür eingerichtet wird.

Ist SASL (oder anderes) aktiviert, kannst du dich via Telnet auch nicht mehr Anmelden. Du bekommst dann die Fehlermeldung ala "No secure connection" oder sowas. Und eine sichere Verbindung lässt sich eben nicht so einfach einrichten damit man das ganze testen kann.

Deswegen Einträge z.B. so setzen: "smtpd_use_tls=no", "smtpd_sasl_auth_enable=no" etc.

Genaueres kann man dazu nur sagen, wenn du eine Fehlermeldung per Telnet bekommst. Abhängig was du bekommst oder nicht bekommst würde ich die Konfiguration kontrollieren und vereinfachen, sodass du dich anmelden kannst. Man kann z.B. mal probieren Telnet direkt via SSH vom Server zu starten, vielleicht gilt der Login nur von einer lokalen Konsole.

 

[RQj7]

Okay, fail2ban habe ich jetzt installiert die config ist ja eig cshon fast selbsterklärend, hatte ich garnicht gedacht.....

Nene, ich bekomm die Fehlermeldung hier:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready.
. login admin@[domain] [passwd]
. NO [AUTHENTICATIONFAILED] Authentication failed.
. login test1@[domain] [passwd]
. BAD Error in IMAP command received by server.

zur Info: Admin gibts als systemuser, test1 als vmail-virtuellen user oder mailbox? nach der oben genannten Anleitung...

Aber: Ich werde Kolab 3.0 installieren, da hab ich dann hoffentlich nicht mehr solche Probleme.... (außer du hättest direkt ne Lösung für mich parat??)


@all:
Brauche trotzdem noch Hilfe bezüglich des RAID 1 Problems. Kennt sich damit jemand aus?

 

[andy_0]

Nein, nicht sofort. Aber schau dir das mal an. Du hast ein IMAP Error. Das hat erst mal gar nichts mit Postfix zu tun. Was für Logins möglich sind, siehst du woher du deine Logins beziehst (vermutlich Postfixadmin).

Solltest du z.B. Kolab einsetzen lösche vorher die verwendete Software (Postfix, Dovecot, ...) und entferne die Konfigurationsdateien. Nicht das es da zu Problemen kommt. Kolab hat ein Repository für Debian Wheezy.

Ich sag übrigens nicht, dass du mit Kolab nichts konfigurieren musst, ein Großteil wird aber von der Suite abgenommen, außerdem haben sie eine ordentliche Dokumentation (http://docs.kolab.org/de-DE/Kolab_Groupware/3.0/html/Community_Installation_Guide/index.html). Für den Aufwand bekommst du dann auch mehr als triviales "Mail versenden und Mail empfangen" sondern eine komplette Groupware.

Wir können unsere Konfiguration im Bereich Datenträger vergleichen. Mein Server hat zwei HDDs die im Raid 1 laufen. In der /etc/fstab steht folgendes:

proc /proc proc defaults 0 0
/dev/md0 none swap sw 0 0
/dev/md1 /boot ext3 defaults 0 0
/dev/md2 / ext4 defaults 0 0

Ka was man im Bezug auf die Raid Konfiguration vergleichen könnte.

 

[RQj7]

Okay. Danke. Aber wo bzw. wie kann ich den IMAP Fehler abändern, so dass es dann vlt funktioniert? Postfixadmin habe ich genau nach dieser Anleitung oben konfiguriert...

Jaja, das ist schon klar aber ich hab mir gestern auch die Dokumentation von Kolab mal angeschaut gehabt, ich fands cool

Danke dafür, bei mir sieht die Datei wiefolgt aus:

/dev/md1	/		ext3    defaults        1 1
/dev/sda2	none		swap    sw 	        
/dev/sdb2	none		swap    sw 	        
/dev/vg00/usr   /usr    	ext4    defaults        0 2
/dev/vg00/var   /var    	ext4    defaults        0 2
/dev/vg00/home	/home		ext4	defaults	0 2
devpts		/dev/pts	devpts  gid=5,mode=620  0 0
none		/proc		proc    defaults        0 0
none		/tmp	tmpfs   defaults        0 0

Wenn ich versuche md3 zu monten kommt das hier:

root@[host]:~# mount /dev/md3 /mnt/
mount: unknown filesystem type 'LVM2_member'

root@[host]:~# apt-get install initramfs-tools mdadm
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
initramfs-tools ist schon die neueste Version.
mdadm ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
root@[host]:~# modprobe linear
root@[host]:~# modprobe multipath
root@[host]:~# modprobe raid0
root@[host]:~# modprobe raid1
root@[host]:~# modprobe raid5
root@[host]:~# modprobe raid6
root@[host]:~# modprobe raid10
root@[host]:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md3 : active raid1 sdb3[0] sda3[1]
      970470016 blocks [2/2] [UU]

md1 : active raid1 sda1[0] sdb1[1]
      4194240 blocks [2/2] [UU]

unused devices: <none>

Kann damit jemand was anfangen?

 

[andy_0]

Der Mountvorgang für LVM Volums ist anders. Schau mal hier (http://www.linux-sxs.org/storage/fedora2ubuntu.html). Ich glaube ja, dein /dev/md3 soll bei dir /home darstellen? Schau mal die Zeile /dev/vg00/home /home an, da wird das LVM Volume vg00 als /home gemounted.

 

[RQj7]

Naja ich hab das jetzt mal nach der Seite von dir gemacht und erhalte:

root@[host]:~# apt-get install lvm2
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
lvm2 ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

root@[host]:~# modprobe dm-mod

root@[host]:~# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "vg00" using metadata type lvm2

root@[host]:~# vgchange -ay vg00
  3 logical volume(s) in volume group "vg00" now active

root@[host]:~# lvs
  LV   VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert
  home vg00 -wi-ao 4,00g
  usr  vg00 -wi-ao 4,00g
  var  vg00 -wi-ao 4,00g

Ich denke das heißt, dass die vg00 (Volume group) nur aus home@4GB, usr@4GB und var@4GB besteht. der Rest - also die 993,8GB (/dev/md3) kann ich dort nirgendwo finden.... Ich versuche jetzt mal mich imt 1und1 in Verbindung zu setzen, vlt wissen die was...Oder ich bekomme wenigstens dort eien Info nach was ich suchen muss/kann...

Ergänzung (18. April 2013)

Also... ich hab es jetzt geschafft, das Problem mit dem raid zu lösen. Jetzt kann ich auch sagen, dass es weniger ein problem, sondern her eine "Unwissenheit" war. 1und1 struckturiert irgendwie die Hilfe derzeit um und da funktioniert die Suche noch nicht perfekt (Aussage des Mitabeiters am Telefon).

Was ich jetzt herausgefunden habe ist, dass das gesamte Raid (1) mit einem LVM organisiert wird. Sodass jeder Administrator solch eines Servers sich den freien Speicherplatz individuell "partitionieren" kann. Indem er mit

 vgdisplay -v [volumegroupname]

den freien Speicherplatz usw ausliest und dann entweder ein neues Volume erstellt oder ein bestehendes vergrößert. Vorgegeben sind ja var mit 4GB, usr mit 4GB und home mit 4GB. Das soll (laut Hilfe) dem Administrator größtmögliche Freiheiten lassen...

Achja, hier mal die Hilfe-seiten Links:

Partitionierung eines Servers verändern

Anlegen eines neuen Volumes auf dem Server

Vergrößern eines bestehenden Volumes auf dem Server



Ich kann nur sagen, dass ich es jetzt endlich geschafft habe und mich nun an meien Virtualisierung usw machen kann

VIELEN DANK an andy_0, der mir bei diesem Thema sehr hilfreich zur Seite stand

Baustelle 1 und 2 sind nun (closed).



Postfixadmin bzw. alles andere in dieser Richtung werde ich mich ab dem WE drum kümmern, muss jetzt erstmal ein bissl Party machen, auf diesen Erfolg

 

[andy_0]

Ist echt super wenn dann nach ein paar Tagen was funktioniert. Mit Linux hat man noch Erfolgserlebnisse .

 

[RQj7]

Naja ich hab ja glaube schon fast 3 Wochen das versucht zu lösen... aber nu hab ich's und freu mich

 

[RQj7]

Hallo nochmal Und zwar stehe ich jetzt wiedereinmal vor einem Problemchen...

Problemdetails:
- Squeeze inzwischen auf Wheezy "geupgraded", alles super, funktioniert alles.
- Installation Kolab 3 (als komplett-set) (apt-get install kolab)
- bei der konfiguration mittels "setup-kolab" trat dieser Fehler auf:

root@[host]:~# setup-kolab -d 9 
2013-04-24 18:09:10,497 pykolab.setup DEBUG [31257]: No component selected, continuing for all components
2013-04-24 18:09:10,513 pykolab.conf DEBUG [31257]: Setting kolab_default_locale to 'en_US' (from defaults)
2013-04-24 18:09:10,514 pykolab.conf DEBUG [31257]: Setting mail_attributes to ['mail', 'alias'] (from defaults)
2013-04-24 18:09:10,514 pykolab.conf DEBUG [31257]: Setting mailserver_attribute to 'mailhost' (from defaults)
2013-04-24 18:09:10,515 pykolab.conf DEBUG [31257]: Setting loglevel to 50 (from defaults)
2013-04-24 18:09:10,516 pykolab.conf DEBUG [31257]: Setting imap_virtual_domains to 'userid' (from defaults)
2013-04-24 18:09:10,516 pykolab.conf DEBUG [31257]: Setting cyrus_annotations_retry_interval to 1 (from defaults)
2013-04-24 18:09:10,517 pykolab.conf DEBUG [31257]: Setting ldap_unique_attribute to 'nsuniqueid' (from defaults)
2013-04-24 18:09:10,517 pykolab.conf DEBUG [31257]: Setting address_search_attrs to ['mail', 'alias'] (from defaults)
2013-04-24 18:09:10,518 pykolab.conf DEBUG [31257]: Setting config_file to '/etc/kolab/kolab.conf' (from the default values for CLI options)
2013-04-24 18:09:10,518 pykolab.conf DEBUG [31257]: Setting loglevel to 'CRITICAL' (from the default values for CLI options)
2013-04-24 18:09:10,519 pykolab.conf DEBUG [31257]: Setting php_ini_path to None (from the default values for CLI options)
2013-04-24 18:09:10,519 pykolab.conf DEBUG [31257]: Setting answer_yes to False (from the default values for CLI options)
2013-04-24 18:09:10,520 pykolab.conf DEBUG [31257]: Setting quiet to False (from the default values for CLI options)
2013-04-24 18:09:10,520 pykolab.conf DEBUG [31257]: Setting fqdn to '[host].[domain]' (from the default values for CLI options)
2013-04-24 18:09:10,521 pykolab.conf DEBUG [31257]: Setting anonymous to False (from the default values for CLI options)
2013-04-24 18:09:10,521 pykolab.conf DEBUG [31257]: Setting debuglevel to 0 (from the default values for CLI options)
2013-04-24 18:09:10,522 pykolab.conf DEBUG [31257]: Setting timezone to None (from the default values for CLI options)
2013-04-24 18:09:10,522 pykolab.conf DEBUG [31257]: Setting logfile to '/var/log/kolab/pykolab.log' (from the default values for CLI options)
2013-04-24 18:09:10,523 pykolab.conf DEBUG [31257]: Setting options from configuration file
2013-04-24 18:09:10,524 pykolab.conf DEBUG [31257]: Reading configuration file /etc/kolab/kolab.conf
2013-04-24 18:09:10,531 pykolab.conf DEBUG [31257]: Setting config_file to '/etc/kolab/kolab.conf' (from CLI, verified)
2013-04-24 18:09:10,531 pykolab.conf DEBUG [31257]: Setting loglevel to 'CRITICAL' (from CLI, not checked)
2013-04-24 18:09:10,532 pykolab.conf DEBUG [31257]: Setting php_ini_path to None (from CLI, not checked)
2013-04-24 18:09:10,533 pykolab.conf DEBUG [31257]: Setting answer_yes to False (from CLI, not checked)
2013-04-24 18:09:10,533 pykolab.conf DEBUG [31257]: Setting quiet to False (from CLI, not checked)
2013-04-24 18:09:10,534 pykolab.conf DEBUG [31257]: Setting fqdn to '[host].[domain]' (from CLI, not checked)
2013-04-24 18:09:10,534 pykolab.conf DEBUG [31257]: Setting anonymous to False (from CLI, not checked)
2013-04-24 18:09:10,535 pykolab.conf DEBUG [31257]: Setting debuglevel to 9 (from CLI, verified)
2013-04-24 18:09:10,536 pykolab.conf DEBUG [31257]: Setting logfile to '/var/log/kolab/pykolab.log' (from CLI, not checked)

Please supply a password for the LDAP administrator user 'admin', used to login
to the graphical console of 389 Directory server.

Administrator password [aJ1XqciWJWmu06k]:
Confirm Administrator password:

Please supply a password for the LDAP Directory Manager user, which is the
administrator user you will be using to at least initially log in to the Web
Admin, and that Kolab uses to perform administrative tasks.

Directory Manager password [qVsxHeePUytreDV]:
Confirm Directory Manager password:

Please choose the system user and group the service should use to run under.
These should be existing, unprivileged, local system POSIX accounts with no
shell.

User [dirsrv]:
Group [dirsrv]:

This setup procedure plans to set up Kolab Groupware for the following domain
name space. This domain name is obtained from the reverse DNS entry on your
network interface. Please confirm this is the appropriate domain name space.

[domain] [Y/n]: Y

The standard root dn we composed for you follows. Please confirm this is the root
dn you wish to use.

dc=[domain,teil1],dc=[domain,teil2] [Y/n]: Y

Setup is now going to set up the 389 Directory Server. This may take a little
while (during which period there is no output and no progress indication).

2013-04-24 18:09:39,141 pykolab.setup INFO Setting up 389 Directory Server
2013-04-24 18:09:39,513 pykolab.setup DEBUG [31257]: Setup DS stdout:
2013-04-24 18:09:39,513 pykolab.setup DEBUG [31257]: Error: the server already exists at '/etc/dirsrv/slapd-[host]'
Please remove it first if you really want to recreate it,
or use a different ServerIdentifier to create another instance.
Error: Could not create directory server instance '[host]'.
Exiting . . .
Log file is '/tmp/setupfuRi6H.log'


2013-04-24 18:09:39,514 pykolab.setup DEBUG [31257]: Setup DS stderr:
2013-04-24 18:09:39,514 pykolab.setup DEBUG [31257]:
Shutting down 389 DS instance [host]: ....
Starting 389 DS instance [host]: ....
update-rc.d: using dependency based boot sequencing

Please supply a Cyrus Administrator password. This password is used by Kolab to
execute administrative tasks in Cyrus IMAP. You may also need the password
yourself to troubleshoot Cyrus IMAP and/or perform other administrative tasks
against Cyrus IMAP directly.

Cyrus Administrator password [Q-Pl2m4Efxn0K7o]:
Confirm Cyrus Administrator password:

Please supply a Kolab Service account password. This account is used by various
services such as Postfix, and Roundcube, as anonymous binds to the LDAP server
will not be allowed.

Kolab Service password [yrgvXsgoCTAAzE6]:
Confirm Kolab Service password:
2013-04-24 18:10:34,547 pykolab.setup INFO Writing out configuration to kolab.conf
2013-04-24 18:10:34,551 pykolab.setup INFO Inserting service users into LDAP.
2013-04-24 18:10:34,552 pykolab.auth DEBUG [31257]: Called for domain None
2013-04-24 18:10:34,553 pykolab.auth DEBUG [31257]: Using section kolab and domain [domain]
2013-04-24 18:10:34,553 pykolab.auth DEBUG [31257]: Using section kolab and domain [domain]
2013-04-24 18:10:34,554 pykolab.auth DEBUG [31257]: Connecting to Authentication backend for domain [domain]
2013-04-24 18:10:34,558 pykolab.auth DEBUG [31257]: Section kolab has auth_mechanism: 'ldap'
2013-04-24 18:10:34,559 pykolab.auth DEBUG [31257]: Starting LDAP...
2013-04-24 18:10:34,745 pykolab.auth DEBUG [31257]: Connecting to LDAP...
2013-04-24 18:10:34,746 pykolab.auth DEBUG [31257]: Attempting to use LDAP URI ldap://localhost:389
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.set_option
((17, 3), {})
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.set_option
((17, 3), {})
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.simple_bind
(('cn=Directory Manager', '[directority-manager-pw]', None, None), {})
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.unbind_ext
((None, None), {})
*** Try 1. reconnect to ldap://localhost:389...
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.set_option
((17, 3), {})
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.set_option
((17, 3), {})
*** 1. reconnect to ldap://localhost:389 successful, last operation will be repeated
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.simple_bind
(('cn=Directory Manager', '[directority-manager-pw]', None, None), {})
*** <ldap.ldapobject.ReconnectLDAPObject instance at 0x16bd710> ldap://localhost:389 - ReconnectLDAPObject.add_ext
(('uid=cyrus-admin,ou=Special Users,dc=[domain,teil1],dc=de',
  [('surname', 'Administrator'),
   ('uid', 'cyrus-admin'),
   ('objectclass',
    ['top', 'person', 'inetorgperson', 'organizationalperson']),
   ('userPassword', '[cyrus-pw]'),
   ('givenname', 'Cyrus'),
   ('cn', 'Cyrus Administrator')],
  None,
  None),
 {})
Traceback (most recent call last):
  File "/usr/sbin/setup-kolab", line 42, in <module>
    setup.run()
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/__init__.py", line 43, in run
    components.execute('_'.join(to_execute))
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 170, in execute
    execute(component)
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 202, in execute
    components[component_name]['function'](conf.cli_args, kw)
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py", line 383, in execute
    auth._auth.ldap.add_s(dn, ldif)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 194, in add_s
    msgid = self.add(dn,modlist)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 191, in add
    return self.add_ext(dn,modlist,None,None)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 176, in add_ext
    return self._ldap_call(self._l.add_ext,dn,modlist,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}
root@[host]:~#

Wie kann ich nun diesen Fehler beheben und komplett konfigurieren?

 

[Daaron]

Läuft denn bereits ein LDAP-Server, insbesondere auf Port 389?

 

[andy_0]

Richtig. Ich denke du solltest das ganze ohne LDAP Agent installieren.

 

[RQj7]

Also der LDAP-Server läuft meiner Meinung nach nicht... wie installiere ich das ohne ldap? Also die einzelnen Pakete installieren und nicht das metapaket 'kolab'?

also kolab-imap , kolab-mta , kolab-webadmin , kolab-webclient ? laut http://docs.kolab.org/de-DE/Kolab_G...y_Installation_Guide-Installation-Packagelist

Ich werde euch dann morgen oder sa bescheid sagen, obs funkt...

Achja, die deinstallation mit apt-get remove oder lieber mit purge wegen den config-dateien?


Und noch eine Frage: In Debian Wheezy, genauer dem apache2 - Gibts da keine 'httpd.conf' mehr?

 

[Daaron]

installier doch erst einmal separat den LDAP-Server und konfigurier ihn sauber.
Wenn du noch nix sinnvolles (oder zu viel sinnloses) konfiguriert hast, dann ist purge die bessere Wahl.

Was Wheezy angeht: kein Plan. Ich glaub Ubuntu 12.04 hatte noch eine. Kann grad nicht gucken. Ich achte da nicht drauf, ich konfigurier das eh alles auf VHost-Basis in /etc/apache2/sites-available/
Wie die Config am Ende heißt ist eh Wurst. Das Leben wird nur viel einfacher, wenn man die Configs thematisch, eben z.B. pro VHost, sortiert.

 

[andy_0]

Apache2 hat keine httpd conf. Die Konfiguration für die Sites werden, wie von Daaron korrekt gesagt, in einer oder mehreren Dateien in der /etc/apache2/sites-available/ hinterlegt. Ich persönlich mag alle EInträge in einer Konfiguration, solange es nicht gar zu viele werden. Ansonsten hat man bei Fehlersuche oder Anpassungen unter Umständen ein ordentliches Dateispringen.

Ich glaube ich hab die Kolab Anwendungen einzeln installiert, kann es dir aber nicht genau sagen. LDAP hab ich definitiv keinen, das benötige ich nicht bzw. will ich gar nicht (kein Single Sing On und Co. benötigt)

 

[Daaron]

Apache2 hat keine httpd conf.

Grad mal nachgeguckt. Sowohl mein lokales Ubuntu 12.04 als auch unser Debian 6 Server hier haben eine httpd.conf. Beim lokalen Ubuntu ist sie leer, beim Debian hab ich irgendwann mal eine Deny From All für /var/www (zur Sicherheit, alles liegt in VHosts. soll keiner über IP ran kommen) eingetragen.
Sie wird also, wenn sie existiert, ausgewertet. Sie spielt eben nur keine Rolle.

Ich persönlich mag alle EInträge in einer Konfiguration, solange es nicht gar zu viele werden. Ansonsten hat man bei Fehlersuche oder Anpassungen unter

einfach mit a2dissite Seite für Seite abschalten. Sobald der Server sauber startet gucken, was in der letzten Seite falsch war.

Genau dafür nutz ich eben gerne Tools wie Froxlor oder ISPConfig: man kann nicht viel falsch konfigurieren, die Dinger kümmern sich. Man kann zwar auch keine extrem alternativen Konfigurationen anlegen, aber will man das? ISPConfig unterstützt z.B. sowohl apache2-mpm-itk (definitiv besser als mpm-prefork) als auch php5-fpm, zusätzlich zum üblichen fcgi, mod_php und suPHP.

 

[RQj7]

Okay, Danke - für die schnellen Antworten! Kolab werde ich mich morgen nocheinmal ransetzen...

Bei dem Apache: Okay Das ganze in vHosts zu konfiguriern ist ja auch ne Möglichkeit... Hatte mich damit noch nicht so sehr beschäftigt...

Trotzdem: danke!!