Syndrom

Witam, Gdy wywyołuje połączenie telnet na port ssh trwa to setną sekundy. Natomiast gdy próbuje przejść cały proces zawisa na prompt: debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. I po około 5-10s przechodzi logowanie Ktoś spotkał się z tym? Dodam, że UseDNS no jest ustawione i w ogóle to raczej nie ma związku bo połączenie nawiązał i klucze wymienił

Tak, zobacz verbose na czym wisi, a na czym by wisiało jak by byl to dns

Debian 8.3 64bit. Zaktualizowany. W pliku /etc/ssh/sshd_config wstawiłem UseDNS no

Testowałeś jak powyżej ? Bo jeśli tak to nie jest to zgodne z RFC i wtedy serwery będą odrzucać. Skonfiguruj sobie klienta pocztowego albo skorzystaj z webmaila i wtedy sprawdź. Wyślij do @gmail i sprawdź headera co tam widasz, powinno być coś takiego: Received-SPF: pass (google.com: domain of rootalert@XXX designates 7.7.1.6 as permitted sender) client-ip=7.7.1.6;

1) nie dubluj postów 2) potrzebujesz rekordów SPF DKIM DMARC 3) jak nie wiesz co to jest to poczytaj

Ustawienie rekordów SPF (głównie gmail) oraz DKIM i DMARC dla hotmail

Witam, Przed chwilą dostałem maila fakowego z serwera hekko podszywającego się pod SlaskDataCenter: W załączniku faktura z 7-dniowym terminem płatności, . -- Tomasz Milczarek SlaskDatacenter.pl Ul. Rembertowska 2/4 02-540 Wrocław Mail zawiera zipa z fakturą, a w niej doc z makrami, które są zaszyfrowane i korzystają z ostatniej dziury Adobe. Pozdrawiam

Zrobiłem test. Wyłączyłem wszystkie kontenery i włączyłem. Niestety problem nie znikł. Póki co killall systemd rozwiązuje problem. Wszystko się przeładowuje

@kafi - dzięki Ad1) jest ok Ad2) na nie działającym np: 235, 158, 146 Na działającym np: 149 138 Ad3) Zatrzymałem około 19 konetnerów i efekt bez zmian, czyli dalej sieje. Podejrzewam, że w jakiś sposób nie zwalnia zasobów, bo restartcie przez jakiś czas jest ok a potem znowu dzieję się dziwne rzeczy. Sprawdzę jeszcze korelację z prockami.

Dzięki to już zawsze wiem gdzie szukać, a strace na dbusa raczej nie zapodam. Może ktoś jeszcze miał podobne rzeczy. Dodam, że stoją tam lxc/docker kontenery

Limity nie zmieniane, ale to nie ma wpływu. Host z problemem: Dec 30 10:24:50 X systemd[1]: Too many concurrent connections, refusing # lsof |wc -l 456553 # ps -ef|wc -l 3320 # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 516317 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 516317 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # cat /etc/debian_version 8.2 Taka sama konfiguracja, host nie ma problemu: # lsof |wc -l 923374 # ps -ef|wc -l 1633 # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 516317 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 516317 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # cat /etc/debian_version 8.2

Dedyk, Debian 8 64bit

Ty tak na poważnie ?:-) Wklejasz te wszystkie 3 komendy do dowolnego pliku, nadajesz uprawnienia +x i wykonujesz jako bash dowlony_plik Albo dodajesz na początku informacje o interpreterze #!/bin/bash nadajesz uprawnienie +x i uruchamiasz ./dowlony_skrypt

Ostatnio pojawił się dziwny problem na serwerze: BŁĄD: root@ser1:~# service sshd reload Error: Too many open files root@ser1:~# ulimit -n 65536 root@ser1:~# lsof |wc -l 647819 root@ser1:~# ps -ef|wc -l 2154 DZIAŁA root@ser2:~# service sshd reload root@ser2:~# ulimit -n 65536 root@ser2:~# lsof|wc -l 1068022 root@ser2:~# ps -ef|wc -l 2126 Ktoś coś z tego rozumie ? Pozatym i tak ulimit ma ograniczenia.

Też o tym myślałem, ale dlatego wkleiłem 2 przykłady by warto można było zauważyć, że ulimit nie ma wpływu. Poza tym ulimit na open files ma i tak limit. Takie zachowania są na fizycznych serwerach.

otrs

chyba przez spację się to gryzie i czy napewno w tych lokalizacjach jest obraz oraz initrd? /NWA_PXE/Linux Debian 8.1.0 i386/live/debian.vmlinuz1 Mój przykładowy wygląda tak: default 1 prompt 0 timeout 30 ONTIMEOUT local menu title ########## PXE Boot Menu ########## label 1 menu label ^1) Install CentOS 7 x64 with Local Repo kernel centos7/vmlinuz append initrd=centos7/initrd.img ks=http://10.0.0.100/ks/ks.cfg ramdisk_size=1000000 nomodeset ip=dhcp vnc vncpassword=onet123 headless

No to tego pxeserva.cfg pokaż. Tam powinno być odowołanie do kernela oraz obrazu intrd

Jak wygląda pxelinux.cfg ? Pokaż ls -lR na katalogu tftp

oVirt to już kobyła, zobacz to: https://www.webvirtmgr.net/

parametr Server na agencie jeszcze i potem sprawdź zabbix_get czy dasz radę się połączyć z serwera do agenta

Mail jest html ? Zawiera obrazki ? Linki ?

Napewno dobry interejs? jak testujesz? z zewnątrz czy z wewnątrz? Nie masz blokowanych tych portówn na INPUT ?

sysctl net.ipv4.conf.all.forwarding=1 i zacznie

Skąd wiesz, że nie ma? Podaj wynik: iptables -t nat -L -v -n sysctl net.ipv4.conf.all.forwarding