2013-08-26 10 views
8

Szukałem> 5 dni, próbowałem wielu sztuczek i wskazówek, a nawet próbowałem przekonać autora lsync do pomocy, ale wszystko na próżno.Konfiguracja lsync do używania loginu innego niż root

Mam 2 serwery Red Hat 6.3, które muszą zsynchronizować swoje katalogi z obrazami po przesłaniu obrazu. Nie możemy kontrolować, do którego serwera zostanie załadowany, ale nie zostanie załadowany do drugiego, gdy zostanie przesłany.

Po prostu muszę móc polecić lsync używanie poświadczeń innego użytkownika, innych niż root. Nasz zespół ds. Bezpieczeństwa informacji nie zezwala na dostęp bez uprawnień administratora. Nie mogę powiedzieć, że ich obwiniam.

Mam konto, które ma dostęp sudo, aby wykonać wszystko, czego potrzebuje, aby pliki zostały przesłane do miejsca docelowego Chociaż mogę uzyskać rsync, aby wykonać synchronizację dobrze, to kończy się niepowodzeniem z błędem uprawnień odmowy podczas uruchamiania z lsync.

Mogę nawet skopiować polecenie wykonane przez lsync z dziennika, usunąć nawiasy kwadratowe i pomyślnie zsynchronizować. Tak, jestem prawie pewien, że to lsync jest przyczyną problemu. Po prostu dlatego, że jest uruchamiany jako root. Skrypt powłoki zmusza go do działania jako root. Próbowałem nawet zmienić go na konto użytkownika innego niż root, a wszystkie pliki pomocnicze zostały zmienione razem ze skryptem i nadal nie chce się zsynchronizować.

Oto szczegóły na temat skryptów i plików, które mam: OS: Red Hat Linux w wersji 6.3 (Santiago) lsyncd plik konfiguracyjny:

---- 
-- 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, 
    } 
} 

plik rsyncd.conf z linią:

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 

Plik rsyncd.conf został zmieniony tak, aby używał innego identyfikatora uid/gid, ponieważ właśnie to chciałem zmienić na.

Oto dziennik błędów z 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. 

UWAGA: I odkażane pliki i zakłada Zrozumiałem wszystko o zamiarze złożenia wniosku o tym, gdzie źródłem i celem powinno być.

Tak, właśnie tak jesteśmy jasne na celu:

  1. Mam 2 serwery WWW, które są symetryczne obciążenie.
  2. Obrazy zostaną przesłane bez kontroli, do którego serwera trafiają.
  3. Projektuję architekturę synchronizacji, używając lsyncd/rsync jako demona do aktualizacji obu serwerów podczas przesyłania. Oznacza to, że oba serwery będą musiały uruchomić polecenie lsyncd/rsyncd bez usuwania. Żadne usuwanie nie zakłada, że ​​jeśli oba serwery mają inny obraz w tym samym czasie, to który serwer najpierw sprawdził cel, usuwałby plik z celu, ponieważ nie znajdował się w źródle.

Rozmawiali o próbach zorientowania się, jak przekierować obrazy na jeden serwer, a następnie moglibyśmy użyć opcji usuwania, aby oba serwery były poprawnie synchronizowane bez obawy o posiadanie usług synchronizacji na obu serwerach i być może brakujące. z powodu czasu. Ponadto, nie wiem, co się stanie, jeśli jeden plik jest otwarty, a drugi serwer próbuje go usunąć.

Jestem zdesperowany, ponieważ nie mogę nawet poprosić autora o pomoc.Być może nie da się tego zrobić, ale wydaje się, że ta potężna aplikacja będzie miała tę głupią małą wadę, która sprawi, że będzie całkowicie bezużyteczna dla tych, którzy mają obawy związane z bezpieczeństwem.

Dzięki!

+2

dostałeś nigdzie z tym? –

+0

Wszelkie kontakty w tej sprawie? –

+0

Przechodząc przez to samo. Trudno uwierzyć, że nie ma żadnego praktycznego rozwiązania dla użytkownika innego niż root. Mogę po prostu zezwolić na root logowania na cel. – Hal50000

Odpowiedz

8

musisz ustawić nazwę użytkownika i plik kluczy w części rsyncopts pliku lsyncd.conf (na ubuntu jest to /etc/lsyncd/lsyncd.conf.lua). Plik kluczy musi być obecny na hoście, na którym działa demon lsyncd.

sync{ 
    default.rsyncssh, 
    source="/path/to/source", 
    host="target.example.org", 
    targetdir="/path/on/target", 
    rsyncOpts={"-e", "/usr/bin/ssh -l someuser123 -i /home/someuser123/.ssh/id_rsa"} 
} 
+7

To mi pomoże. Należy zauważyć, że z ** lsyncd 2.1 **, rsyncOpts nie jest obsługiwany. Musi on zostać zastąpiony przez: 'rsync = { rsh ="/usr/bin/ssh -l someuser123 -i/home/someuser123/.ssh/id_rsa ", }' [Zobacz to] (https: // github.com/axkibe/lsyncd/wiki/Lsyncd%202.1.x%20%E2%80%96%20Layer%204%20Config%20%E2%80%96%20Default%20Behavior#defaultrsync) – JBENOIT

+0

Działa tylko pliki na cel zawsze będzie własnością 'someuser123' bez względu na właściciela na serwerze źródłowym – Hal50000

+1

Możesz po prostu ustawić rsyncOpts -eo, aby również zachować właściciela. Lub -og, aby zachować właściciela i grupę. Istnieją również opcje zachowania daty utworzenia, patrz "man rsync", aby uzyskać szczegółowe informacje. – edlerd

0
settings { 
     logfile = "/var/log/lsyncd/lsyncd.log", 
     statusFile = "/var/log/lsyncd/lsyncd.status" 
} 

sync { 
     default.rsyncssh, 
     source = "/home/vagrant/local", 
     host = "[email protected]", 
     targetdir = "/home/vagrant/remote", 
     rsync = { 
       rsh = "/usr/bin/ssh -l vagrant -i /home/vagrant/.ssh/id_rsa -o StrictHostKeyChecking=no" 
     } 
} 
Powiązane problemy