lsync-Konfiguration für die Verwendung von nicht-root-logins

Habe ich gesucht > 5 Tage, versucht durch zahlreiche tricks und Tipps, und sogar versucht, den Autor des lsync zu helfen, aber vergeblich.

Ich habe 2 Red Hat 6.3 web-Server zu synchronisieren, Ihre Bild Verzeichnisse, wenn ein Bild hochgeladen wird. Wir können nicht kontrollieren, welcher server es wird hochgeladen, aber es wird nicht geladen, der andere, wenn es hochgeladen ist.

Brauche ich einfach, um in der Lage sein zu sagen, lsync, um einen anderen Benutzer verwenden die Anmeldeinformationen, die andere als root. Unser information security team nicht erlauben ohne Passwort root-Zugriff. Kann nicht sagen, dass ich Ihnen die Schuld.

Habe ich ein Konto mit sudo-Zugriff auf alles, was es braucht, um die Dateien an Ihren Bestimmungsort. Obwohl ich kann rsync zum ausführen der sync einwandfrei, es schlägt fehl, eine Genehmigung verweigert Fehler beim ausführen von lsync.

Kann ich sogar kopieren der Befehl ausgeführt wird, die von lsync aus dem Protokoll, entfernen Sie die eckigen Klammern und es synchronisiert sich erfolgreich. Also, ich bin mir ziemlich sicher, dass es lsync, das das problem verursacht. Einfach, weil es läuft als root. Das shell-Skript zwingt, es als root laufen. Ich habe sogar versucht, es zu ändern, um eine nicht-root-account und alle unterstützenden Dateien verändert wurden zusammen mit dem script und es immer noch weigert zu synchronisieren.

Hier sind die details auf die Skripts und Dateien, die ich habe:
OS: Red Hat Linux version 6.3 (Santiago)
lsyncd config-Datei:

 ----
 -- User configuration file for lsyncd.
 --
 -- Simple example for default rsync, but executing moves through on the target.
 --
 -- For more examples, see /usr/share/doc/lsyncd*/examples/
 -- 
 -- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"}

settings{
    logfile = "/var/log/lsyncd.log",
    statusFile = "/var/log/lsyncd-status.log",
    delay = 1,
}
sync {
    default.rsyncssh,
    source="<Absolute path to source directory>",
    host      = "<Host IP>",
    targetdir = "<Absolute path to target directory>",
    rsync = {
        binary = "/usr/bin/rsync",
        rsh = "sudo -u <Domain>\\<User ID> ssh",
        sparse = true,
        update = true,
        links = true,
        times = true,
    }
}

rsyncd.conf-Datei:

log file = /var/log/rsyncd.log
pid file = /var/log/rsyncd.pid
allow = localhost
deny = *
list = true
uid = 16777218
gid = 16777222
read only = false
timeout=600
use chroot = true

[Test1]
path = "<Absolute path to target/source>"
comment = Test for remote transfer

Den rsyncd.conf-Datei wurde geändert, um die Verwendung einer anderen uid/gid wie das ist, was ich wollte, es zu sein geändert.

Hier ist das Fehlerprotokoll aus lsyncd.log:

Thu Aug 22 07:58:57 2013 Debug: daemonizing now.
Thu Aug 22 07:58:57 2013 Function: Inotify.addWatch(<Absolute Path to Source> )
Thu Aug 22 07:58:57 2013 Inotify: addwatch( <Absolute Path to Source> )-> 1 
Thu Aug 22 07:58:57 2013 Call: getAlarm( )
Thu Aug 22 07:58:57 2013 Alarm: runner.getAlarm returns: (true)
Thu Aug 22 07:58:57 2013 Masterloop: immediately handling delays.
Thu Aug 22 07:58:57 2013 Call: cycle( )
Thu Aug 22 07:58:57 2013 Function: invokeActions( "Sync1", (Timestamp: 5491559.47) )
Thu Aug 22 07:58:57 2013 Normal: recursive startup rsync: <Absolute Path to Target> -> <Host IP>:<Absolute Path to Target>
Thu Aug 22 07:58:57 2013 Exec: /usr/bin/rsync [--delete] [--ignore-errors] [-usltS] [--rsh=sudo -u <Domain>\<User ID> ssh] [-r] [<Absolute Path to Source>] [<Host IP>:<Absolute Path to Target>]
Thu Aug 22 07:58:57 2013 Function: write( (Timestamp: 5491559.47) )
Thu Aug 22 07:58:57 2013 Statusfile: writing now
Thu Aug 22 07:58:57 2013 Call: getAlarm( )
Thu Aug 22 07:58:57 2013 Alarm: runner.getAlarm returns: (false)
Thu Aug 22 07:58:57 2013 Masterloop: going into select ( no timeout )
rsync: Failed to exec sudo: Permission denied (13)
rsync error: error in IPC code (code 14) at pipe.c(84) [sender=3.0.6]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in IPC code (code 14) at io.c(600) [sender=3.0.6]
Thu Aug 22 07:58:57 2013 Call: collectProcess( )
Thu Aug 22 07:58:57 2013 Delay: collected an event
Thu Aug 22 07:58:57 2013 Error: Temporary or permanent failure on startup of "<Absolute Path to Target>". Terminating since "insist" is not set.

HINWEIS: ich sanitized der Dateien und angenommen ich verstanden, alle von der Absicht, die Anwendung zu, wo die Quelle und Ziele sein sollte.

So, nur so sind wir klar auf das Ziel:

  1. Ich habe 2 web-Servern, die Lastenausgleich sind.
  2. Bilder werden hochgeladen, ohne zu Steuern, welchen server Sie gehen.
  3. Ich bin der Gestaltung einer sync-Architektur mit lsyncd/rsync als daemon zur Aktualisierung von Servern, wenn der upload erfolgt. Dies bedeutet, dass beide Server laufen müssen lsyncd/rsyncd mit nicht löschen. Nein löschen geht davon aus, dass wenn beide Server bekam ein anderes Bild in der gleichen Zeit dann die jemals-server überprüft das Ziel zuerst, es würde die Datei löschen auf dem Ziel-da es sich nicht auf die Quelle.

Waren Sie reden, versuchen herauszufinden, wie man direkt die Bilder auf einem server und wir könnten dann verwenden Sie die option löschen, um die beiden Server synchronisieren, genau, ohne sich Gedanken darüber, dass die sync-Dienste auf beiden Servern und vielleicht fehlt einem da der timing. Auch, weiß nicht, was passieren wird, wenn eine Datei geöffnet ist und die anderen server versucht, es zu löschen.

Ich bin verzweifelt, da ich nicht einmal den Autor, um zu helfen. Vielleicht, es kann nicht getan werden, aber es scheint, dass eine app diese leistungsstarke, hätte dies eine dumme kleine Fehler, wäre es völlig unbrauchbar, von denen, die haben Bedenken bezüglich der Sicherheit.

Dank!

  • Hast du überall mit diesem?
  • Führt auf dieser?
  • Gehen durch die gleiche Sache. Schwer zu glauben, es gibt keine brauchbare Lösung für nicht-root. Ich könnte zulassen, dass root-Anmeldungen auf das Ziel.
InformationsquelleAutor freshpowder | 2013-08-26
Schreibe einen Kommentar