Gestern konnte ich meine Emails bei mail.google.com über die Weboberfläche nicht abrufen, alle anderen Google Dienste konnte ich erreichen.
Ich dachte an ein DNS Problem bei meinem Provider und versuchte es heute morgen noch einmal, leider ging es immer noch nicht. Eine Namensauflösung per host scheiterte ebenfalls mit der Aussage unbekannte Domäne.
In einem Forum fand ich dann die Lösung: Fritzbox neu starten.
Damit jemand im Auftrag eines Verteilers eine Email versenden kann, müssen zwei Punkte beachtet werden:
1. Der Verteiler darf nicht von der globalen Adressliste ausgeblendet sein.
Mit dem folgenden PS Kommando lässt sich die Option -HiddenFromAddressListEnabled anzeigen.
Der Wert ist Standardmäßig auf False gesetzt.
Get-DistributionGroup Verteilername | fl Hidden*
Der Wert kann entsprechend mit dem Set-CMDLet geändert werden.
Set-DistributionGroup Verteilername -HiddenFromAddressListEnabled $false (oder $true)
2. Es muss ein gesondertes Recht gesetzt werden.
Add-ADPermission -Identity verteiler -User benutzer -AccessRights ExtendedRight -ExtendedRights „Send As“
Beim Ausführen des Befehls in der Exchange Konsole kann es zu folgendem Fehler kommen:
Zusätzliche Informationen: Access is denied.
Active Directory-Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
+ CategoryInfo : WriteError: (0:Int32) [Add-ADPermission], ADOperationException
+ FullyQualifiedErrorId : D6227AC5,Microsoft.Exchange.Management.RecipientTasks.AddADPermission
Das Problem ist, das bestimmte Rechte für das „Exchange Trusted Subsystem“ fehlen.
Lösung
In der Active Directory MMC in der Erweiterten Ansicht die Eigenschaften des Verteilers aufrufen. Im Reiter Sicherheit auf Erweitert gehen, dort den Benutzer „Exchange Trusted Subsystem“ die Rechte „Berechtigung lesen, Berechtigung ändern“ geben.
Im Anschluss kann der Powershellbefehl erneut ausgeführt werden.
Add-ADPermission -Identity verteiler -User benutzer -AccessRights ExtendedRight -ExtendedRights „Send As“
Bei der Anmeldung am Gerrit kam es zu der Meldung Provider is not supported, or was incorrectly entered.
In der error_log Datei kamen Meldungen wie
java.net.URISyntaxException: Illegal character in authority at….
….
ERROR com.google.gerrit.httpd.auth.openid.OpenIdServiceImpl : Cannot discover OpenID…
Auf den ersten Blick war die eingegebene URL für die Anmeldung korrekt, auf den zweiten Blick stellte sich heraus das vor der URL ein Leerzeichen war. Nachdem das Leerzeichen entfernt wurde, funktionierte auch die Anmeldung.
Seit der openssh Version 5 ist es möglich einen Benutzer der sich per ssh anmelden in einem Ordner einzusperren.
So bin ich vorgegangen:
Als erstes habe ich eine Gruppe angelegt namens sftponly. Den Benutzer bzw die Benutzerin lieschen habe ich der Gruppe hinzugefügt.
groupadd sftponly
useradd lieschen
usermod -aG sftponly lieschen
Die /etc/ssh/sshd_config habe ich wie folgt angepasst:
Subsystem sftp internal-sftp
Match Group sftponly
ChrootDirectory /srv/transfer
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
Im Anschluss der Anpassung den sshd Dienst neu starten.
Als letztes müssen noch die Ordner erstellt werden:
mkdir -p /srv/transfer
chown root:sftponly /srv/transfer
chmod 755 /srv/transfer
mkdir -p /srv/transfer/lieschen
chown lieschen:sftponly /srv/transfer/lieschen
chmod 700 /srv/transfer/lieschen
Ein Benutzer der in der Gruppe sftponly ist, darf sich nur per sftp mit dem Server verbinden. Bei der Anmeldung landet er im Ordner /srv/transfer. Dort sieht er zwar alle Ordner, kann jedoch nur auf seinen zugreifen.
Ich bin nach dieser Anleitung vorgegangen: http://meshfields.de/sftp-chroot-centos/
In der Gerrit Version 2.3.1 kann es vorkommen das sich der interne sshd Dienst aufhängt, dann kann nicht mehr auf die Repositorys zugegriffen werden. Das Problem scheint aufzutreten, wenn ein oder mehrere Jenkins Server auf das gerrit zugreifen.
Greift ein Benutzer auf das gerrit zu, kommen in den sshd logs die login, aktion und logout Meldungen. Meldet sich jedoch der im jenkins hinterlegte Benutzer an, gibt es hauptsächlich nur login Meldungen. Irgendwann folgt dann die Meldung das die Verbindung gekilled wurde.
Über netstat -an | grep 29418 sieht man auch, das die Jenkins Server viele Verbindungen öffnen und nicht wieder schließen.
In der error Log Datei kommt dann folgende Meldung:
[2012-09-25 01:11:01,557] WARN org.apache.sshd.server.session.ServerSession : Exception caught
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:218)
at sun.nio.ch.IOUtil.read(IOUtil.java:191)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:214)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:673)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
[2012-09-25 01:16:01,279] WARN org.apache.sshd.server.session.ServerSession : Exception caught
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:218)
at sun.nio.ch.IOUtil.read(IOUtil.java:191)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:214)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:42)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:673)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Ein Update auf 2.4.1 behebt das Problem.
Kleine Howto für ein gerrit update:https://www.itbasic.de/gerrit-update/