Kategorie: Blog

Mit ipfire core Version 100 bis zur aktuellen 110 haben wir das Phänomen, dass eingehende SIP INVITES von der FW blockiert wurden, obwohl es einen ständigen Ping Pong gibt zwischen TK-Anlage dahinter und Provider in der Form:

IP 192.168.2.251.5060 > 195.185.37.60.5064: SIP: OPTIONS sip:sip.easybell.de SIP/2.0
IP 195.185.37.60.5064 > 192.168.2.251.5060: SIP: SIP/2.0 200 Alive

Kommt jetzt jedoch ein Anruf rein, wird dieser durch die ipfire FW blockiert:

06:06:08.098003 IP 195.185.37.60.5060 > 192.168.2.251.5060: SIP: INVITE sip:zielnummer@öffentliche-IP:5060 SIP/2.0

May 17 06:06:23 ipfire kernel: DROP_FORWARD IN=red0 OUT=green0 MAC=BEKANNT SRC=195.185.37.60 DST=192.168.2.251 LEN=764 TOS=0x00 PREC=0x00 TTL=57 ID=63961 DF PROTO=UDP SPT=5060 DPT=5060 LEN=744

Wir haben uns jetzt mit einer FW-Regel beholfen, die eingehend obigen Block ausnimmt. Da wir davor noch eine weitere FW besitzen, die korrekt nattet, sehen wir hier kein Sicherheitsproblem. Die FW davor hat korrekt erkannt, dass dies Teil einer bestehenden Verbindung ist.

Möchte man den installierten Controller von einem Server auf einen neuen Server mit selber IP umziehen, reicht es, über die Oberfläche Settings – > Maintenance ein Backup zu ziehen und dies im neuen einzuspielen.

Hat der neue Server jedoch eine neue IP, ist es nötig, die AccessPoints zurückzusetzen. Am Einfachsten geht das über den noch aktiven alten Kontroller. AP auswählen und Forget auswählen. Dadurch wird der AP in den Auslieferungszustand versetzt und kann jetzt vom neuen Kontroller adoptiert werden.

Wenn zwei Personen in einer Rufgruppe sind, kann kein Anruf mehr für ein individuelles Telefon dieser Rufgruppe übernommen werden per BLF.

Es muss dann die Rufgruppen-Nummer auf die BLF-Taste programmiert werden.

Wir hatten hier nur „Keine Rückmeldung“ erhalten am Telefon.

Merkwürdiges Verhalten mit Outlook heute bemerkt. Outlook 2010 mit Exchange und IMAP-Konto. Senden & Empfangen von Mails ging mit jedem Konto problemlos. Jedoch Antworten auf E-Mails mit dem IMAP-Konto nicht möglich über postfix SMTP-Server.

in den Logs nur zu sehen:

Timeout after DATA

tcpdump ebenso wenig hilfreich:

<code>

18:14:43.785624 IP ts01.awssol.lan.59463 > ucs09.awssol.lan.smtp: Flags [P.], seq 12:55, ack 176, win 512, length 43
E..S'.@...R7.......     .G..f....3.^P.......MAIL FROM: <max.mustermann@tld>

18:14:43.802875 IP ucs09.awssol.lan.smtp > ts01.awssol.lan.59463: Flags [P.], seq 176:190, ack 55, win 229, length 14
E..6.\@.@...... .......G.3.^f...P.......250 2.1.0 Ok

18:14:43.803348 IP ts01.awssol.lan.59463 > ucs09.awssol.lan.smtp: Flags [P.], seq 55:96, ack 190, win 512, length 41
E..Q'.@...R8.......     .G..f....3.lP.......RCPT TO: <anja.ankel@tld>

18:14:43.821818 IP ucs09.awssol.lan.smtp > ts01.awssol.lan.59463: Flags [P.], seq 190:204, ack 96, win 229, length 14
E..6.]@.@...... .......G.3.lf...P.......250 2.1.5 Ok

18:14:43.822317 IP ts01.awssol.lan.59463 > ucs09.awssol.lan.smtp: Flags [P.], seq 96:102, ack 204, win 512, length 6
E...'.@...RZ.......     .G..f....3.zP.......DATA

18:14:43.822443 IP ucs09.awssol.lan.smtp > ts01.awssol.lan.59463: Flags [P.], seq 204:241, ack 102, win 229, length 37
E..M.^@.@...... .......G.3.zf...P.......354 End data with <CR><LF>.<CR><LF>

18:14:43.886306 IP ts01.awssol.lan.59463 > ucs09.awssol.lan.smtp: Flags [.], ack 241, win 512, length 0
E..('.@...R_.......     .G..f....3..P....z..
18:14:46.433386 IP ts01.awssol.lan.59463 > ucs09.awssol.lan.smtp: Flags [P.], seq 102:108, ack 241, win 512, length 6
E...'.@...RX.......     .G..f....3..P.......QUIT

</code>

Wie man sieht, schickt der Client (Outlook) einfach keine Daten nach der Aufforderung von DATA.

Problem war, dass in Outlook irgendwie die Rechte gefehlt haben, dass die ausgehende/gesendete Mail abgelegt werden konnte. Wir haben jetzt eine dritte Datendatei in Outlook angelegt und die zum Standard gemacht. Ab dann war Versenden möglich.

Auch wenn das Exchange-Konto temporär entfernt wurde, war Versenden möglich.

Stand 06.02.2017

Unser aktuelles Projekt war die Migration einer alten Zarafa-Installation zu Kopano mit ~ 100 Benutzern. Es läuft, aber sehr holprig:

S/MIME teilweise defekt – verschlüsselte Mails aus Nicht-WebApp können nicht entschlüsselt werdn

Das Backup-Skript hat Probleme mit Umlauten und Schrägstrichen in Verzeichnisnamen – nach dem Restore waren Teile von Mails & Kontakten usw. verschwunden/gelöscht

Outlook Clients die sich ein Postfach teilen verursachen teilweise Race-Conditions, was zu sehr hoher Serverlast führt (eher unüblicher Einsatzzweck)

WebApp muss gelegentlich zurückgesetzt werden

WebMeeting ist von Spreed – klappt aufgrund der Architektur nur mit Turn-Server – diesen stellt Kopano kostenlos zur Verfügung

Übersetzung ist nicht vollständig und falsch – deutsche Übersetzung speziell bei Filterregeln

Darstellungsproblem bei globalem Adressbuch bei mehr als 60-70 Einträgen – infinite scroll bug

Manche Mails werden von der WebApp verschluckt, wenn diese „scheinbar“ defekt sind. Andere clients haben kein Problem damit.

Apache Segfault beim Setzen von Berechtigungen in WebApp – nur in der Beta-Version derzeit

Sehr beschränkte Outlook-Anbindung ab Outlook 2016. Wegfall von MAPI-Schnittstelle – Alternative Active-Sync mit fehlenden Funktionen (fremde Postfächer öffnen, Mails zwischen Konten verschieben uvm.).

 

Jetzt zu den positiven Seiten:

Die derzeit noch beste Alternative zum teuren Microsoft Exchange

Umfängliche Groupware mit Active-Sync Anbindung für mobile Clients

Kopano-Files ist genial – einfacher Zugriff über z.B. SMB auf vorhandenen Dateiserver – überall Zugriff auf Dateien

Günstiger Preis

Offene Entwicklung, einfache Möglichkeit der Einflussnahme auf Entwicklung über Forums & Tickets

Deutscher Support mit eigener Hotline-Nummer

Gute zukünftige Aussichten

Unabhängigkeit von Microsoft Exchange

Office 365 schön und gut. Benötigt man jedoch ein E-Mail Archiv, erlaubt es Microsoft nicht, mit Journal-Filter Regeln alle Mails einfach in ein weiteres Exchange Online Postfach zu kopieren.

Details hier:

http://windowsitpro.com/blog/why-exchange-online-hates-journal-mailboxes

Update 23.01.2016: Weil wir gefragt wurden, wie man es dann richtig macht. Am Besten Inhouse einen Mailserver bereitstellen, welcher E-Mails von einem Pop/Imap-Konto abholt. An dieses E-Mail Konto mit einer Regel in Exchange Online, alles als Kopie senden:

 

xmlstarlet sel -t -v "*//counter[@name='inj_msgs']/@reset" status.xml

Danke Flo für den Tipp.

Es gibt viele Upgradepfade. Half uns nichts, denn wir wollten das Backend von DB auf LDAP umstellen.

Ab Zarafa 7.2.x gibt es zarafa-backup-plus welches fast identisch ist zu kopano-backup für Kopano.

Somit am Tag X ein Backup gemacht auf dem alten System mit ‚zarafa-backup-plus -l warning -w 8‘

Hierbei ist uns auch aufgefallen, dass die Sicherung von 300GB auf 70GB geschrumpft ist. Das kommt von den bereits gelöschten Objekten, die ja noch in der DB hinterlegt waren – jetzt aber nicht mitgesichert werden sowie die oprhaned stores.

Beim Restore auf der Zielmaschine dann die Verwunderung – wo sind die serverseitigen Filterregeln?

Scheint ein Bug in kopano-backup zu sein. Es hilft nur ein erneuter Restore aller Benutzer – aber nur mit dem Schalter –meta-only

Und schon sind die zusätzlichen Filterregeln wieder da.

 

 

LVM besitzt die Option auto_activation_volume_list.

Dies reicht jedoch in einem Cluster mit shared storage und LVM on top nicht aus, um den Volume Groups exklusiv zu initialiseren. Siehe:

https://www.redhat.com/archives/linux-lvm/2016-November/msg00023.html

Also lock manager und clvmd nötig.

Für einen Test muss in der VG auch zwingend ein LV existieren – sonst wird die VG nicht korrekt initialisiert.

Wir verwenden IPMI zweierlei. Zu Monitoring mit Zabbix und als Fence-Device für STONITH.

Scheinbar ist das aber zuviel für unsere Fujitsu RX Server und so gibts regelmäßig:

external/ipmi[14468]: ERROR: error executing ipmitool: Get Session Challenge command failed: Out of space Error: Unable to establish LAN session Error: Unable to establish IPMI v1.5 / RMCP session
WARN: external_status: ‚ipmi status‘ failed with rc 1
ERROR: external/ipmi device not accessible.

Wir haben jetzt mal den Abfrageintervall in Zabbix erhöht und es scheint sich zu bessern.