ipcimek atiranyitasa belso halozatra

2009-12-16 bef zés Linux Levlist 
sziasztok,

adott 3 telephely (192.168.1.0, 192.168.2.0, 192.168.3.0) amit a
szolgaltato fog osszekotni
belso vpn-el, illetve a szolgaltato valamelyik adatparkjaban lesz egy
virtualis szerver, ami a tuzfal/proxy funkciot
latja majd el, ennek a belso laban a 192.168.4.0 halozat lesz, kulso
laban keresztul erik majd el az internetet
a telephelyek.

ez eddig vszinuleg menni is fog vszinu, sima iptables nat a belso
halozatokra, illetve proxy.

viszont, hogy szebb legyen a tortenet, 2 telephelyen lesz 1-1 dedikalt
gep, akiknek a vilag fele kulon fix ip
cimmel kell latszodniuk, mert ugy tudnak csak csatlakozni egy kulso
adatbazishoz, ha regisztraljak a
fix ipcimuket.

kertem tehat a virtualis szerver kulso labara 3 fix ip cimet.

kerdesem az lenne, hogy hogy lenne az egyszeubb szerintetek.
- 1 kulso lab 1 belso lab, a kulso labon 3 fix ip
- 3 kulso lab fix ip-vel, egy belso lab

illetve hogy tudom megmondani az iptablesnek, hogy ha a
192.168.1.15akar kimenni, akkor eth2n menjen
ha a 192.168.2.15 akkor eth3an menjen, egyebkent mindenki mas az eth1en?

udv / koszi
a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

backup megoldas kliens oldalrol

2009-11-19 bef zés Linux Levlist 
sziasztok,

keresek egy megoldas, amivel a kliens gepekrol (50-80 kliens) automatizalva
mentenek adatokat (dokumentumok pl) egy kozponti szervere.

a kliensek vegyesek, linux illetve xp.

jo lenne, ha vmi agent tipusu megoldas lenne (windows alatt), tehat kikeresi a
mentendoket, felcsatlakozik, lementi, logolja szepen hatterben.

van e vkinek otlete / tapasztalata?

elso korben a google a baculat adta ki, ennek nezegetem most a doksijat,
de gondoltam rakerdezek, hatha van jobb/szebb/ugyesebb...

udv / koszi
a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-07 bef zés Linux Levlist 
2008/7/7 Kiss Gabor [EMAIL PROTECTED]:
:
 tail /var/log/messages
  mingetty[11766]: mingetty: /dev/tty2: cannot get controlling tty:
 Operation not permitted

 tail/tmp/trace2
 11766 open(/dev/tty2, O_RDWR|O_LARGEFILE) = 0
 11766 ioctl(0, TIOCSCTTY)   = -1 EPERM (Operation not permitted)

 Khm... rootként indítottad?

Termeszetesen
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
Kiss Gabor [EMAIL PROTECTED] írta (2008. július 4. 9:16):
 merre/mit keressek?

 Először is rúgj bele az initbe:
 # init q
 Akkor gyorsan megpróbálja újraindítani amit kell.
 Aztán nézd meg melyik logba tojt:
 # ls -lrt /var/log

csak a messagesbe irt:
Jul  4 09:40:30 server init: Re-reading inittab

semmi mas log nem valtozott, a massagesben csak ez az 1 sor jott fel.


 Ha találsz ott valamit elemezzük. Ha nem, akkor spekulálunk tovább.
 Pl. megpróbálhatod kézzel indítani a getty-t, esetleg strace alatt.

ezt hogyan is?
udv / koszi
andras
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
2008/7/4 Lajber Zoltan [EMAIL PROTECTED]:
 On Fri, 4 Jul 2008, Linux Levlist wrote:

  Ha találsz ott valamit elemezzük. Ha nem, akkor spekulálunk tovább.
  Pl. megpróbálhatod kézzel indítani a getty-t, esetleg strace alatt.

 ezt hogyan is?

 Pl: open -c 6 /sbin/getty

server:/ # open
-bash: open: command not found

(a rendszer opensuse 10.3, itt nem talaltam semelyik csomagban /usr/bin/open-t)

udv
andras
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
  Ha találsz ott valamit elemezzük. Ha nem, akkor spekulálunk tovább.
  Pl. megpróbálhatod kézzel indítani a getty-t, esetleg strace alatt.

 ezt hogyan is?

 Pl: open -c 6 /sbin/getty

 server:/ # open
 -bash: open: command not found


hja, openvt :)
de sajna nem inditotta el
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
2008/7/4 Kiss Gabor [EMAIL PROTECTED]:

 In article [EMAIL PROTECTED],
Linux Levlist [EMAIL PROTECTED] linux@mlf.linux.rulez.org writes:
 b.
 Pl. megpr=F3b=E1lhatod k=E9zzel ind=EDtani a getty-t, esetleg strace alat=
 t.

 ezt hogyan is?

 strace -fF -o /tmp/trace /sbin/getty 38400 tty1


huh, bocsi kicsit hosszu a kimenet, remelem nam gaz, ha elkuldom a listara...

server:/ #strace -fF -o /tmp/trace /sbin/mingetty 38400 tty1
server:/ #cat /tmp/trace

11598 execve(/sbin/mingetty, [/sbin/mingetty, 38400, tty1],
[/* 57 vars */]) = 0
11598 brk(0)= 0x804e000
11598 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
11598 open(/etc/ld.so.cache, O_RDONLY) = 3
11598 fstat64(3, {st_mode=S_IFREG|0644, st_size=68667, ...}) = 0
11598 mmap2(NULL, 68667, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ef7000
11598 close(3)  = 0
11598 open(/lib/libc.so.6, O_RDONLY)  = 3
11598 read(3, [EMAIL PROTECTED]...,
512) = 512
11598 fstat64(3, {st_mode=S_IFREG|0755, st_size=1281488, ...}) = 0
11598 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef6000
11598 mmap2(NULL, 1254896, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dc3000
11598 fadvise64(3, 0, 1254896, POSIX_FADV_WILLNEED) = 0
11598 mmap2(0xb7ef, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12c) = 0xb7ef
11598 mmap2(0xb7ef3000, 9712, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ef3000
11598 close(3)  = 0
11598 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc2000
11598 set_thread_area({entry_number:-1 - 6, base_addr:0xb7dc26c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
11598 mprotect(0xb7ef, 4096, PROT_READ) = 0
11598 munmap(0xb7ef7000, 68667) = 0
11598 uname({sys=Linux, node=server, ...}) = 0
11598 uname({sys=Linux, node=server, ...}) = 0
11598 getpid()  = 11598
11598 getsid(0) = 11151
11598 brk(0)= 0x804e000
11598 brk(0x806f000)= 0x806f000
11598 access(/var/run/utmpx, F_OK)= -1 ENOENT (No such file or directory)
11598 open(/var/run/utmp, O_RDWR|O_LARGEFILE) = 3
11598 fcntl64(3, F_GETFD)   = 0
11598 fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
11598 _llseek(3, 0, [0], SEEK_SET)  = 0
11598 alarm(0)  = 0
11598 rt_sigaction(SIGALRM, {0xb7eb6df0, [], 0}, {SIG_DFL}, 8) = 0
11598 alarm(1)  = 0
11598 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 read(3, 
\10\0\0\0F\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11598 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 alarm(0)  = 1
11598 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11598 alarm(0)  = 0
11598 rt_sigaction(SIGALRM, {0xb7eb6df0, [], 0}, {SIG_DFL}, 8) = 0
11598 alarm(1)  = 0
11598 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 read(3, 
\1\0\0\0005N\0\0~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11598 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 alarm(0)  = 1
11598 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11598 alarm(0)  = 0
11598 rt_sigaction(SIGALRM, {0xb7eb6df0, [], 0}, {SIG_DFL}, 8) = 0
11598 alarm(1)  = 0
11598 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 read(3, 
\5\0\0\0_\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11598 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 alarm(0)  = 1
11598 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11598 alarm(0)  = 0
11598 rt_sigaction(SIGALRM, {0xb7eb6df0, [], 0}, {SIG_DFL}, 8) = 0
11598 alarm(1)  = 0
11598 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 read(3, 
\10\0\0\0\0\0\0\0:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11598 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 alarm(0)  = 1
11598 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11598 alarm(0)  = 0
11598 rt_sigaction(SIGALRM, {0xb7eb6df0, [], 0}, {SIG_DFL}, 8) = 0
11598 alarm(1)  = 0
11598 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 read(3, \10\0\0\0K\17\0\0pts/0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11598 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11598 alarm(0)  = 1
11598 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
2008/7/4  [EMAIL PROTECTED]:
 On Fri, Jul 04, 2008 at 11:20:47AM +0200, Linux Levlist wrote:
 11598 close(4)  = 0
 11598 close(3)  = 0
 11598 chown32(/dev/38400, 0, 5)   = -1 ENOENT (No such file or 
 directory)

 Szerintem nem jol van paraméterezve a mingetty, mert a BAUD
 értéket vette device-nek.


 Valamit irt a syslogba is

Jul  4 11:28:24 server mingetty[11627]: mingetty: /dev/38400: No such
file or directory
hmm, van egy masik ugyanilyen gepem (opensuse + hw ugyanaz), de ott
sincs /dev/38400...
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
2008/7/4  [EMAIL PROTECTED]:
 On Fri, Jul 04, 2008 at 11:32:32AM +0200, Linux Levlist wrote:
 Jul  4 11:28:24 server mingetty[11627]: mingetty: /dev/38400: No such
 file or directory
 hmm, van egy masik ugyanilyen gepem (opensuse + hw ugyanaz), de ott
 sincs /dev/38400...

 man mingetty -

 mingetty  [--noclear] [--nonewline] [--noissue] [--nohangup]
 [--nohost-name] [--long-hostname] [--loginprog=/bin/login]
 [--nice=10] [--delay=5]  [--chdir=/home] [--chroot=/chroot]
 [--autologin username] tty

 Itt azt irja, a device-t kell mindenkéépem megadni (tty1, tty2)


/dev/tty1..ttysf van, csak 38400 nincs...
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 

 Amit inditottal, az nem volt jo, mert maskepp kell parameterezni
 a mingetty-t, mint a getty-t.

 Igy probald:
 strace -fF -o /tmp/trace /sbin/mingetty tty1

 De valami blogd fut a /dev/tty1-en amirol nem tudom, hogy
 micsoda, ezert lehet, hogy masik tty-on kellene probalkoznod.


strace -fF -o /tmp/trace2 /sbin/mingetty tty2

a kovetkezoket talaltam:
tail /var/log/messages
 mingetty[11766]: mingetty: /dev/tty2: cannot get controlling tty:
Operation not permitted

tail/tmp/trace2
11766 open(/dev/tty2, O_RDWR|O_LARGEFILE) = 0
11766 ioctl(0, TIOCSCTTY)   = -1 EPERM (Operation not permitted)

googlezgatok eggyet, hogy ez mit jelenthet...

de mivel en nem ertek hozza, azert bemasolom az egesz kimenetet:
cat /tmp/trace2
11766 execve(/sbin/mingetty, [/sbin/mingetty, tty2], [/* 56 vars */]) = 0
11766 brk(0)= 0x804e000
11766 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
11766 open(/etc/ld.so.cache, O_RDONLY) = 3
11766 fstat64(3, {st_mode=S_IFREG|0644, st_size=68667, ...}) = 0
11766 mmap2(NULL, 68667, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f23000
11766 close(3)  = 0
11766 open(/lib/libc.so.6, O_RDONLY)  = 3
11766 read(3, [EMAIL PROTECTED]...,
512) = 512
11766 fstat64(3, {st_mode=S_IFREG|0755, st_size=1281488, ...}) = 0
11766 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f22000
11766 mmap2(NULL, 1254896, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7def000
11766 fadvise64(3, 0, 1254896, POSIX_FADV_WILLNEED) = 0
11766 mmap2(0xb7f1c000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12c) = 0xb7f1c000
11766 mmap2(0xb7f1f000, 9712, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f1f000
11766 close(3)  = 0
11766 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dee000
11766 set_thread_area({entry_number:-1 - 6, base_addr:0xb7dee6c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
11766 mprotect(0xb7f1c000, 4096, PROT_READ) = 0
11766 munmap(0xb7f23000, 68667) = 0
11766 uname({sys=Linux, node=server, ...}) = 0
11766 uname({sys=Linux, node=server, ...}) = 0
11766 getpid()  = 11766
11766 getsid(0) = 11654
11766 brk(0)= 0x804e000
11766 brk(0x806f000)= 0x806f000
11766 access(/var/run/utmpx, F_OK)= -1 ENOENT (No such file or directory)
11766 open(/var/run/utmp, O_RDWR|O_LARGEFILE) = 3
11766 fcntl64(3, F_GETFD)   = 0
11766 fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
11766 _llseek(3, 0, [0], SEEK_SET)  = 0
11766 alarm(0)  = 0
11766 rt_sigaction(SIGALRM, {0xb7ee2df0, [], 0}, {SIG_DFL}, 8) = 0
11766 alarm(1)  = 0
11766 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 read(3, 
\10\0\0\0F\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11766 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 alarm(0)  = 1
11766 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11766 alarm(0)  = 0
11766 rt_sigaction(SIGALRM, {0xb7ee2df0, [], 0}, {SIG_DFL}, 8) = 0
11766 alarm(1)  = 0
11766 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 read(3, 
\1\0\0\0005N\0\0~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11766 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 alarm(0)  = 1
11766 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11766 alarm(0)  = 0
11766 rt_sigaction(SIGALRM, {0xb7ee2df0, [], 0}, {SIG_DFL}, 8) = 0
11766 alarm(1)  = 0
11766 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 read(3, 
\5\0\0\0_\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11766 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 alarm(0)  = 1
11766 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11766 alarm(0)  = 0
11766 rt_sigaction(SIGALRM, {0xb7ee2df0, [], 0}, {SIG_DFL}, 8) = 0
11766 alarm(1)  = 0
11766 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 read(3, 
\10\0\0\0\0\0\0\0:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
384) = 384
11766 fcntl64(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
11766 alarm(0)  = 1
11766 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
11766 alarm(0)  = 0
11766 rt_sigaction(SIGALRM, {0xb7ee2df0, [], 0}, {SIG_DFL}, 8) = 0
11766 alarm(1)  = 0
11766 fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})

Re: fellabu sw raid

2008-07-04 bef zés Linux Levlist 
2008/7/4  [EMAIL PROTECTED]:
 Az alábbi ls kimenete nállad hogy néz ki ?
 ls -la /dev/tty?
 crw-rw 1 root root 4, 0 Jun 30 07:37 /dev/tty0
 crw--- 1 root root 4, 1 Jun 30 07:38 /dev/tty1
 crw--- 1 root root 4, 2 Jun 30 07:38 /dev/tty2
 crw--- 1 root root 4, 3 Jun 30 07:38 /dev/tty3
 crw--- 1 root root 4, 4 Jun 30 07:38 /dev/tty4
 crw--- 1 root root 4, 5 Jun 30 07:38 /dev/tty5
 crw--- 1 root root 4, 6 Jun 30 07:38 /dev/tty6
 crw-rw 1 root root 4, 7 Jun 30 07:37 /dev/tty7
 crw-rw 1 root root 4, 8 Jun 30 07:37 /dev/tty8
 crw-rw 1 root root 4, 9 Jun 30 07:37 /dev/tty9

ilyen volt:
crw-rw 1 root tty  4, 1 Jul  3 10:17 /dev/tty1
crw-rw 1 root tty  4, 2 Jul  3 10:17 /dev/tty2
crw--w 1 root tty  4, 3 Jul  3 10:17 /dev/tty3
crw--w 1 root tty  4, 4 Jul  3 10:17 /dev/tty4
crw--w 1 root tty  4, 5 Jul  3 10:17 /dev/tty5
crw--w 1 root root 4, 6 Jul  3 10:17 /dev/tty6

atirtam olyanra mint a masik mukodo gep:
crw-rw 1 root tty 4, 1 Jul  3 10:17 /dev/tty1
crw-rw 1 root tty 4, 2 Jul  3 10:17 /dev/tty2
crw-rw 1 root tty 4, 3 Jul  3 10:17 /dev/tty3
crw-rw 1 root tty 4, 4 Jul  3 10:17 /dev/tty4
crw-rw 1 root tty 4, 5 Jul  3 10:17 /dev/tty5
crw-rw 1 root tty 4, 6 Jul  3 10:17 /dev/tty6

majd init q, de semmi nem tortent

 Itt a tty1..tty6 -on fut a mingetty

 1:2345:respawn:/sbin/mingetty --noclear tty1
 2:23:respawn:/sbin/mingetty tty2
 3:23:respawn:/sbin/mingetty tty3
 4:23:respawn:/sbin/mingetty tty4
 5:23:respawn:/sbin/mingetty tty5
 6:23:respawn:/sbin/mingetty tty6

nalam ilyen
1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: courier imap + tar

2008-07-03 bef zés Linux Levlist 
 sziasztok!
 egy scriptbol szeretnem lementen a maildireket, veszont a tar mindig
 hibara fut, ugyanis
 a spamek miatt sajnos ejjel 2kor is erkeznek be levelek, valtozik a
 konyvtar tartalom, es
 ezt ugylatszik nem szereti (file changed as we read it).

 Csinálj egy file listát pl. find-el és azt add meg a tar-nak...
 ez talán segít...

sziasztok,

koszi a segitseget mindenkinek.

tehat az eredmeny:
mivel a celkonyvtar egy windowsos megosztason van az rsync kiesett,
lvm-et utolag nem akarok, find-el nem akartam megbonyolitani.

jelenleg a script elejen leallitom az amavisd-t, a postfix ezert ugye nem tudja
tovabbitani a levelet, szepen osszegyul queue-ba, scriptbe maradt a tar+gzip,
a vegen amavisd elindit, +meg egy postqueue -f, es kesz.
ma volt a 2 nap mikor lefutott, ez a alatt nem hozott hibat,
remenykedek, hogy igy marad.

(viccbol az amavisd inditas elott kiirattam egy filebe a mailq tartalmat,
100 db spam volt benne, de hat ki mas is kuldozgetne levelet hajnalban :)

udv es koszi
andras
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: fellabu sw raid

2008-07-03 bef zés Linux Levlist 
 On Wed, 2 Jul 2008, Linux Levlist wrote:
 ez normalis? gondolom a vinyocsere szukseges ezek utan.

 Reszben :)
 Az, hogy a diszk kihal, majd felbukkan, az dszk hiba, nezz utanna, en nem
 biznek benne. De lehet kabel hiba is.
 Az ,hogy pl hotswap eseten kiveszed a diszket, ami sda, majd beraksz egy
 masikat, es az sdc lesz, az megszokott jelenseg.

sziasztok,

hdd csere megtortent, mukodik a raid, minden ok. (kiveve hogy az X elindult, be
lehet jelentkezni/dolgozni, de szoveges konzolom nincs, alt+f1-f6 ures kepernyo
a syslog-ba semmi, a boot.msg-ben talaltam vmit, azt a level vegere beszurom,
most probalom googlezni a megoldast, de ha vkinek van otlete, megkoszonnem)

egy rovid kerdesem meg lenne: sda1-et dd-vel atmasoltam sdb1-re (tudom, tudom
miert nem rakom raidbe, bele fogom, csak most nem lehetet tovabb leallni)
megpedig igy:
dd if=/dev/sda1 of=/root/sda1.out
dd if=/root/sda1.out of=/dev/sdb1

ez elvileg egyezik egy ghostolassal tehat a boot rekordot is atvitte, lehet
rola bootolni?

udv / koszi
andras

boot.msg:
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/server:421
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Could not init font path element /usr/share/fonts/TTF/, removing from list!
Could not init font path element /usr/share/fonts/OTF, removing from list!
noticecheckproc: /usr/sbin/xinetd 3782
noticekillproc: kill(3782,3
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: fellabu sw raid

2008-07-03 bef zés Linux Levlist 
 hdd csere megtortent, mukodik a raid, minden ok. (kiveve hogy az X elindult, 
 be
 lehet jelentkezni/dolgozni, de szoveges konzolom nincs, alt+f1-f6 ures 
 kepernyo
 a syslog-ba semmi, a boot.msg-ben talaltam vmit, azt a level vegere beszurom,
 most probalom googlezni a megoldast, de ha vkinek van otlete, megkoszonnem)

 Fut a getty? (Hat pldnyban.)
 Az initnek kellene indtania az inittab alapjn.
 Ha nem tudja, panaszkodik a logba.
 kissg

szia,

idaig jutottam en is, hogy nem fut :(

server: # ps aux  | grep tty
root  2161  0.0  0.0  26380   508 ?Ssl  Jul03   0:37
/sbin/blogd /dev/tty1
root  5369  0.0  0.2  12804  7208 tty7 Ss+  Jul03   0:18
/usr/bin/Xorg -br -nolisten tcp :0 vt7 -auth
/var/lib/xdm/authdir/authfiles/A:0-7TTyPc
root 10380  0.0  0.0   2044   664 pts/0S+   07:17   0:00 grep tty

a inittab jonak tunik:

server:~ # cat /etc/inittab | grep -v '#'
id:5:initdefault:
si::bootwait:/etc/init.d/boot
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
ls:S:wait:/etc/init.d/rc S
~~:S:respawn:/sbin/sulogin
ca::ctrlaltdel:/sbin/shutdown -r -t 4 now
kb::kbrequest:/bin/echo Keyboard Request -- edit /etc/inittab to let
this work.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
sh:12345:powerfail:/sbin/shutdown -h now THE POWER IS FAILING
1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

logokban (messages, boot.msg) semmit nem talalok, ami hibara utalna,
vagy osszefug az inittabal, ami vagy azert van, mert bena vagyok, vagy
mert nincs benne vmi, aminek benne kene lennie, de ugye nem talalom,
mert nem tudom mi az :)
merre/mit keressek?

udv / koszi
andras
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

fellabu sw raid

2008-07-02 bef zés Linux Levlist 
sziasztok,

van egy szerver (OpenSuse 10), benne 2 sata vinyo (sda, sdb), sw
raidben, legnagyobb oromomre az sda elhasalt.

mivel anno sw-rol nem tudtam bebootoltani, a particiok a kovetkezok a vinyokon:
-sda1 - /boot - ext3
-sda2 - / - Linux raid autodetect - md0
-sda3 - / - swap
-sda4 - /data - Linux raid autodetect - md2 (md1 a swap volt regen)

-sdb1 - /boot2 - ext3
-sdb2 - / - Linux raid autodetect - md0
-sdb3 - / - swap
-sdb4 - /data - Linux raid autodetect - md2 (md1 a swap volt regen)

most az sda elhasalt, a szerver meg fut. az sda1 particio
nortonghostal at lett imagelve, tehat elvileg
arrol is be tud bootolni, ha atdugom a 0-as sata portra.

elso kerdes, 160Gb-os Seagate vinyok vannak benne. ha nem kapok pont
ilyet (ami igen valoszinu),
akkor mit ajanlotok, vegyek masfajta 160ast, vagy vegyek inkabb
nagyobbat, hogy biztos raferjen
a particio? mik a tapasztalatok?

meg sosem csinaltam sw raid visszaallitast, ezert inkabb elore
kerdezek, ezeket tervezem:
1. adatmentes masik gepre (folyamatban :)
2. szerver leallit, sda-lehuz, sdb atdug sata 0 portra, bebootol
(aggodom az fstab miatt, lasd lent)
3. az mdstat azt fogja kiirni, hogy fellabu, es sdb hinayzik (remenyeim szerint)
4. sdb kivetele a tombokbol: mdadm --remove /dev/md0 /dev/sdb , mdadm
--remove /dev/md2 /dev/sdb
5. server leallit, uj vinyo radug
6. bebootol, cfdisk /dev/sdb megcsinalom a particiokat (kell e
particionalni egyaltalan, vagy az mdadm megteszi?
itt erdekes meg az is, hogy mi van ha kisebb/nagyobb vinyot kapok.
kisebbre a szinten 160 gigas, de nehany
byte-al kisebbet ertem, gondolom nem minden gyarto 160 Gigas vinyoja
byte-ra annyit kapacitasu...)
7. mdadm --add /dev/md0 /dev/sdb , mdadm --add /dev/md2 /dev/sdb
8. megvarom a szinkronizalas veget, szerver ujraindit, nortonghostal
sda1 - sdb1
9. server elindul, minden jo, orulunk.

ez az otlet, amit eddig osszeszedtem, ha vmi hujeseg van benne legyszi
irjatok meg

udv / koszi
andras

ami meg kellhet info:

cat /etc/fstab
/dev/md0 /ext3   acl,user_xattr1 1
/dev/md2 /abasext3   acl,user_xattr1 2
/dev/disk/by-id/scsi-SATA_ST3160815AS_5RA2HD4J-part1 /boot
   ext3   acl,user_xattr1 2
/dev/disk/by-id/scsi-SATA_ST3160815AS_5RA2H7MG-part1 /boot2
   ext3   acl,user_xattr1 2
proc /procproc   defaults  0 0
sysfs/sys sysfs  noauto0 0
debugfs  /sys/kernel/debugdebugfsnoauto0 0
usbfs/proc/bus/usbusbfs  noauto0 0
devpts   /dev/pts devpts mode=0620,gid=5   0 0
/dev/disk/by-id/scsi-SATA_ST3160815AS_5RA2HD4J-part3 swap

cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md2 : active raid1 sda4[0](F) sdb4[1]
  133154680 blocks super 1.0 [2/1] [_U]
  bitmap: 53/254 pages [212KB], 256KB chunk

md0 : active raid1 sda2[0](F) sdb2[1]
  20972784 blocks super 1.0 [2/1] [_U]

cat /boot2/grub/menu.lst
# Modified by YaST2. Last modification on Sat Jan 12 12:08:38 UTC 2008
default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,0)/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3
root (hd0,0)
kernel /vmlinuz-2.6.22.5-31-default root=/dev/md0 vga=0x317
resume=/dev/md1 splash=silent showopts
initrd /initrd-2.6.22.5-31-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3
root (hd0,0)
kernel /vmlinuz-2.6.22.5-31-default root=/dev/md0 vga=normal
showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0
edd=off 3
initrd /initrd-2.6.22.5-31-default
  bitmap: 97/161 pages [388KB], 64KB chunk
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: fellabu sw raid

2008-07-02 bef zés Linux Levlist 
On Wed, 2 Jul 2008, Erdelyi Gabor wrote:
   7. mdadm --add /dev/md0 /dev/sdb , mdadm --add /dev/md2 /dev/sdb
  OK
 Nem OK! Particiok vannak a tombokben, nem diszkek!

sziasztok,

eloszor is koszi az infokat, lassan megvan az utemterv...
erdekes dolog tortent, most alltam volna neki vinyot cserelni, de
eszrevettem valalmit:
a raid tombol ugye eltunt az sda, probaltam felmountolni, de nem is
latta, gondoltam meghalt.
de! most veletlen megtalaltam, hogy ottvan, megvannak a particiok meg az adatok,
csak nem sda hanem sdc! a server uptime-ja 160 nap, a raid meg 3-4
napja mukodott,
tehat nem ujrainditaskor cserelodott, hanem menet kozben!

a logok alapjan csak a vinyoval lesz gond, de hogy kerult at menet
kozben az sdc-re?
ez normalis? gondolom a vinyocsere szukseges ezek utan.

udv / koszi
andras

a logokba ilyeneket talaltam (ezekkel van tele):
Jul  1 22:02:07 server kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x9 action 0xa frozen
Jul  1 22:02:07 server kernel: ata3: hard resetting link
Jul  1 22:02:09 server kernel: ata3: SATA link up 1.5 Gbps (SStatus
113 SControl 310)
Jul  1 22:02:10 server kernel: ata3.00: configured for UDMA/100
Jul  1 22:02:10 server kernel: ata3: EH pending after completion,
repeating EH (cnt=4)
Jul  1 22:02:10 server kernel: ata3: EH complete
Jul  1 22:02:10 server kernel: sd 3:0:0:0: [sda] 312581808 512-byte
hardware sectors (160042 MB)
Jul  1 22:02:10 server kernel: sd 3:0:0:0: [sda] Write Protect is off
Jul  1 22:02:10 server kernel: sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
Jul  1 22:02:10 server kernel: sd 3:0:0:0: [sda] Write cache: enabled,
read cache: enabled, doesn't support DPO or FUA

Jul  2 00:49:30 server kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x9 action 0xa frozen
Jul  2 00:49:30 server kernel: ata3: hard resetting link
Jul  2 00:49:32 server kernel: ata3: COMRESET failed (errno=-32)
Jul  2 00:49:32 server kernel: ata3: reset failed (errno=-32),
retrying in 8 secs
Jul  2 00:49:32 server kernel: ata3: hard resetting link
Jul  2 00:49:34 server kernel: ata3: COMRESET failed (errno=-32)
Jul  2 00:49:34 server kernel: ata3: reset failed (errno=-32),
retrying in 8 secs
Jul  2 00:49:34 server kernel: ata3: hard resetting link
Jul  2 00:49:36 server kernel: ata3: COMRESET failed (errno=-32)
Jul  2 00:49:36 server kernel: ata3: reset failed (errno=-32),
retrying in 33 secs
Jul  2 00:49:36 server kernel: ata3: hard resetting link
Jul  2 00:49:39 server kernel: ata3: SATA link down (SStatus 0 SControl 310)
Jul  2 00:49:39 server kernel: ata3: failed to recover some devices,
retrying in 5 secs
Jul  2 00:49:44 server kernel: ata3: hard resetting link
Jul  2 00:49:44 server kernel: ata3: SATA link down (SStatus 0 SControl 310)
Jul  2 00:49:44 server kernel: ata3.00: limiting speed to UDMA/100:PIO3
Jul  2 00:49:44 server kernel: ata3: failed to recover some devices,
retrying in 5 secs
Jul  2 00:49:49 server kernel: ata3: hard resetting link
Jul  2 00:49:49 server kernel: ata3: SATA link down (SStatus 0 SControl 310)
Jul  2 00:49:49 server kernel: ata3.00: disabled
Jul  2 00:49:50 server kernel: ata3: EH pending after completion,
repeating EH (cnt=4)
Jul  2 00:49:50 server kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x1 action 0xb
Jul  2 00:49:50 server kernel: ata3: hard resetting link
Jul  2 00:49:50 server kernel: ata3: SATA link down (SStatus 0 SControl 310)
Jul  2 00:49:50 server kernel: ata3: EH complete
Jul  2 00:49:50 server kernel: ata3.00: detaching (SCSI 3:0:0:0)
Jul  2 00:49:50 server kernel: sd 3:0:0:0: [sdc] Synchronizing SCSI cache
Jul  2 00:49:50 server kernel: sd 3:0:0:0: [sdc] Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Jul  2 00:49:50 server kernel: sd 3:0:0:0: [sdc] Stopping disk
Jul  2 00:49:50 server kernel: sd 3:0:0:0: [sdc] START_STOP FAILED
Jul  2 00:49:50 server kernel: sd 3:0:0:0: [sdc] Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK

Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] 312581808 512-byte
hardware sectors (160042 MB)
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Write Protect is off
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Write cache: enabled,
read cache: enabled, doesn't support DPO or FUA
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] 312581808 512-byte
hardware sectors (160042 MB)
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Write Protect is off
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Write cache: enabled,
read cache: enabled, doesn't support DPO or FUA
Jul  2 01:03:40 server kernel:  sdc: sdc1 sdc2 sdc3 sdc4
Jul  2 01:03:40 server kernel: sd 3:0:0:0: [sdc] Attached SCSI disk
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: courier imap + tar

2008-07-01 bef zés Linux Levlist 
On Tue, Jul 01, 2008 at 10:42:33AM +0200, Linux Levlist wrote:
 van e erre vmi lehetoseg, hogy a tar kihagyja/atugorja ezeket a hibakat?
 vagy mas otlet a mentesre?
 leallitani nem akarom a levelezest erre az idoszakra, csak vegso esetben.

rsync, dirvish
--
CZW

rsync se szereti, lehet, hogy azert mert a celmappa egy windowsos
megosztason (ntfs) van?

rsync -auz /home/albert /home/antali /mnt/backup/mail_home/home
rsync: rename 
/mnt/backup/mail_home/home/albert/Maildir/cur/.1186477700.V903I9d001bM980086.mail.domain.hu:2,S.DbuUzy
- albert/Maildir/cur/1186477700.V903I9d001bM980086.mail.domain.hu:2,S:
Invalid argument (22)
(ezekbol az uzenetekbol sok jon)

(ha a /tmp-be szinkronizalom, akkor megy, tehat samba/ntfs keverhet
be, biztos nem szereti
a filenevben a kettospontot, vesszot...)

udv
a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: courier imap + tar

2008-07-01 bef zés Linux Levlist 
Hi!


 egy scriptbol szeretnem lementen a maildireket, veszont a tar mindig
 hibara fut, ugyanis
 a spamek miatt sajnos ejjel 2kor is erkeznek be levelek, valtozik a
 konyvtar tartalom, es
 ezt ugylatszik nem szereti (file changed as we read it).

 leallitani nem akarom a levelezest erre az idoszakra, csak vegso esetben.


Mi lenne akkor, ha az MTA két konfigot kapna? Arra gondolok, hogy
lenne egy normál és egy queue-only. Mentés elött nyomsz egy
restartot a queue-only konfiggal, elvégzed a mentést, majd ismét
restart a normál konfiggal. Ekkor a mentés alatt a queue-only
mód miatt a levelet az MTA átveszi ugyan, de nem dobja be a címzett
fiókjába csak leteszi a saját spooljába - amit nem mentesz. A mentés
végén pedig nem csak restart az eredeti konfiggal, hanem runq a
spoolba került levelek gyors kiszórása érdekében...

Zsolt

Ui.: a dolog persze így is fejre állhat, ha egy IMAP kilens pont ekkor
tölt fel vagy töröl levelet... Esetleg ezen időre a POP3+IMAP esetleg
leállhat?

hat igen, ezen gondolkodtam en is, be is irtam a scriptbe egy amavisd
stop-ot, lesz ami lesz,
holnap reggel kiderul :) (postfix atveszi, amavisd (spamot szur)
leallit, hajnalba ugyis
csak spam jon, ha vege a mentesnek, ujraindul az amavisd feldolgozza az addig
beesett maileket)

imap-ot nem allitom le egyenlore, hatha nem szukseges, 2 het teszt
alatt kiderul remeljuk.

csak azt furcsalom, hogy a tar miert nem tudja ezt lekezelni, ha
valtozott a file
archivalas alatt, hat valtozott, azert meg nem kellene kiakadnia...

udv / koszi
a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux