Red Hat, Fedora, CentOS

Sziasztok!

Van egy kis problémám CentOS 7 IPIP tunnelingel és gondoltam hátha itt valaki tud segíteni. 

Van két hostom: 10.0.1.107 (host A) és 10.0.0.169 (host B), mindkettő a  255.255.248.0 maszkal. Tudják egymás pingelni semmi gond. A B-én van subnet: 10.20.0.0/16 amit szeretnék elérni az A-ról. Gondoltam csinálok rá egy IPIP tunnelt aminek a két oldal 10.21.1.1 és 10.21.1.2.

host A:

$ nmcli connection add type ip-tunnel ip-tunnel.mode ipip con-name tun0 ifname tun0 remote 10.0.0.169 local 10.0.1.107
Connection 'tun0' successfully added.
$ nmcli connection modify tun0 ipv4.addresses '10.21.1.1/30'
$ nmcli connection modify tun0 ipv4.method manual
$ nmcli connection modify tun0 +ipv4.routes "10.20.0.0/16 10.21.1.2"
$ nmcli connection up tun0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
$ echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/95-IPv4-forwarding.conf
$ sysctl -p /etc/sysctl.d/95-IPv4-forwarding.conf
net.ipv4.ip_forward = 1

host B:

$ nmcli connection add type ip-tunnel ip-tunnel.mode ipip con-name tun0 ifname tun0 remote 10.0.1.107 local  10.0.0.169
Connection 'tun0'  successfully added.
$ nmcli connection modify tun0 ipv4.addresses '10.21.1.2/30'
$ nmcli connection modify tun0 ipv4.method manual
$ nmcli connection up tun0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
$ echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/95-IPv4-forwarding.conf
$ sysctl -p /etc/sysctl.d/95-IPv4-forwarding.conf
net.ipv4.ip_forward = 1

A gond az, hogy a fenti nem mükődik. Nem tudom pingelni a távoli tunnel címeket. Tehát host A-ról a 10.21.1.2-t például. Ugyanakor a tcpdump azt mutatja van forgalom:

a# ping 10.21.1.2
PING 10.21.1.2 (10.21.1.2) 56(84) bytes of data.
^C
--- 10.21.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

b$ tcpdump -nni tun0


12:22:28.379441 IP 10.21.1.1 > 10.21.1.2: ICMP echo request, id 20995, seq 1, length 64
12:22:28.379512 IP 10.21.1.2 > 10.21.1.1: ICMP echo reply, id 20995, seq 1, length 64
12:22:29.378786 IP 10.21.1.1 > 10.21.1.2: ICMP echo request, id 20995, seq 2, length 64
12:22:29.378853 IP 10.21.1.2 > 10.21.1.1: ICMP echo reply, id 20995, seq 2, length 64
12:22:30.378807 IP 10.21.1.1 > 10.21.1.2: ICMP echo request, id 20995, seq 3, length 64
12:22:30.378890 IP 10.21.1.2 > 10.21.1.1: ICMP echo reply, id 20995, seq 3, length 64
12:22:31.378685 IP 10.21.1.1 > 10.21.1.2: ICMP echo request, id 20995, seq 4, length 64
12:22:31.378759 IP 10.21.1.2 > 10.21.1.1: ICMP echo reply, id 20995, seq 4, length 64

Az ip route is szerintem jó:

a# ip route get 10.21.1.2
10.21.1.2 dev tun0 src 10.21.1.1 
    cache expires 433sec mtu 1480 

Firewalld ki van kapcsolva. Van valakinek ötlete? 

Üdv

Választanom kellene valami Red Hat "klónt" házi szerverre.
Az AlmaLinux  és a Rocky Linux közül választanék (mert ezekről hallottam). Esetleg van valami ami hasonlít ezekhez?
Elsőre a Rocky a szimpatikusabb az alapító miatt. Nem akarok valami zsákutca dologba futni, majd 2-3 év után. Ha tudnátok jósolni :-) vagy tanácsot adni.
Köszönet előre is.
 

Üdv!

VBox-ban (6.1.22) próbáltam feltenni a friss C8Stream-et: CentOS-Stream-8-x86_64-20210629-dvd1.iso

Win és Linux alatt is a telepítő lehal a csomagok leöltésénél ismeretlen hibával (valami hasonló). Ha nem aktiválom a hálókártyát a telepítőben, akkor is ugyanaz.

Más is tapasztalta?

Az alábbi fstab fájl beállítás teljesen jó működött a fedora 33-ban.

#cifs

//192.168.1.x/Volume_1                  /mnt/NAS1              cifs        username=dell,password=xxxx,iocharset=utf8,noperm,vers=1.0         0 0
//192.168.1.x/Volume_2                  /mnt/NAS2              cifs        username=dell,password=xxxx,iocharset=utf8,noperm,vers=1.0         0 0
#ssh mount
apa@192.168.1.x:/homenext /mnt/homenextmount fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=100 0 0
#
apa@192.168.1.x:/homeone /mnt/homeonemount fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=100 0 0
#
apa@192.168.1.x:/home /mnt/homemount fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=100 0 0
#
UUID=352dcb10-16f0-4d12-8a98-94fdc7019502  /home/user/.hdd     btrfs    defaults                    0       0
#bind
#
/mnt/NAS1                               /home/user/NAS1                                      none    bind                        0       0
/mnt/NAS2                               /home/user/NAS2                                      none    bind                        0       0
/mnt/homeonemount/Fényképészet          /home/user/homeone                                   none    bind                        0       0
/mnt/homenextmount/Pictures             /home/user/Pictures                                  none    bind                        0       0
/mnt/homenextmount/balinthazisuli       /home/user/Bálint_Házi_Suli                          none    bind                        0       0
/mnt/homemount/ftp/canon_scan           /home/user/ScanTMP                                   none    bind                        0       0
/home/user/.hdd                          /home/user/1T                                        none    bind                        0       0
/home/user/.hdd/Dokumentumok             /home/user/Dokumentumok                              none    bind                        0       0
/home/user/.hdd/LETOLTESEK               /home/user/LETÖLTÉSEK                                none    bind                        0       0
/home/user/.hdd/Képek                    /home/user/Képek                                     none    bind                        0       0
/home/user/.hdd/Videók                   /home/user/Videók                                    none    bind                        0       0
/home/user/.hdd/Letöltések               /home/user/Letöltések                                none    bind                        0       0
#

Van feladat benne rendesen, de működött.

Frissítettem fedora 34-re és a mountolás gyakorlatilag megbolondult.

Abszolút vagylagosan mountolja fel a könyvtárakat bootoláskor. Semmilyen logikát nem találok benne melyiket miért nem csatolja fel. Kiadom a mount -a parancsot és minden ok. Hibaüzenet nélkül lefut és minden a helyén van. 

Egyszerűen nem értem mi változott a Fedora 34-ben ami ezt jelenséget okozza.

  Van esetleg ötlet a megoldásra?

Köszi, ha tudtok segíteni ebben.

AlmaLinux OS Stable Release is live! (https://almalinux.org/blog/almalinux-os-stable-release-is-live/) kapcsán kérdezem.

Sziasztok!

Adott egy Centos7 linux szerver, elég sok sftp kapcsolat van felé, sok mindent futtat, több szállító dolgozik rá, vannak fájmásolások, ütemezések, stb... Szóval elég sok munkát végző szerver.

Egy idő után elkezdenek elfogni az ssh session-ök és emiatt a külső szolgáltató cégünk scriptjei behalnak. 

Sokat googliztam mostanában erre, s tudom, hogy az sshd konfigban lehet ezt szűrni 2 paraméterrel. Megpróbáltuk de hamar jöttek a gondok, így kivettük ezeket a beállításokat. Viszont most 3-4 hét után kezdenek ezek a session gondok elkezdődni.

Tudtok valami olyan parancsot ami egyértelműen kiadja, hogy mennyi session van még vissza, hol állunk. Illetve van -e olyan parancs ami ezt "kinullázza" a szerver újraindítása nélkül. 

Van különbség SSH és SFTP session között?

Köszönöm!!

Sziasztok !

Egyre többször találkozom azzal a Fedora 33 / kde leállításakor, hogy várakozik egy user process miatt.

Eddig a rekord 2:30 volt. Egyszerűen nem értem mire vár. Addig ok, hogy vannak hálózati mappák amiket le kell válasszon. de egy desktop gépnél mi a bánatra kell várni több mint 2 percig?

Nem lehetne csak úgy leállni egy számítógépnek?  :)))

Csak én járok így vagy ez egy Fedora / KDE szolgáltatás?

Hi!

Adott egy Supermicro X11SPH-nCTF alaplap (USB install).

A CentOS8 telepítő megy is, de a hálókártyákat nem ismeri fel. Pontosabban Rufus-sal kiírtam először ISO módban, akkor látta kártyákat, de a telepítő csomagokat nem találta meg.

Erre kiírtam DD módban, ezzel látta a csomagokat, de a hálókártyákat nem látja...(?) :o

USB telepítés után nincs egy hálókártya sem, az nmtui se hoz fel semmit.

Nagyjából egy órával ezelőtt automatikusan megnyílt a firefoxban az about:addons, és mindegyik addonhoz kiírta, hogy could not be verified. Nem is működnek. Az addons portálon mindenre azt írja, 'Installation aborted because the add-on appears to be corrupt.' Mivel nincs még tele az internet a problémára adott jajgatással, a hiba nyilván nálam van. Úgy gondoltam, a teljesség kedvéért ellenőrzöm, hogyan írják/írták alá őket. Letöltöttem az aktuális ffox forrását a repóból (83.0-13.fc33), amiben a cacerts.pem minden tagja érvényes, pontosabban egyiknek sincs 2020 a 'Not After:' mezőjében. És itt elakadtam. Milyen certtel írják alá az addonokat? Akárhogy keresem, magát a certet (és a fölötte lévőket) nem találom.

[EDIT]: az nyilvánvaló, hogy nem cacerttel írnak alá, ebbe ne menjünk bele.

[EDIT2]: megvan, mi történt: https://bugzilla.redhat.com/show_bug.cgi?id=1908018

$ dnf list --installed | egrep '^nss\.x86_64' | sed -r 's/\s+/ /g'
nss.x86_64 3.59.0-2.fc33 @updates-testing

[EDIT3]: Kétszeresen is balfasz voltam. Egyrészt elfelejtettem, hogy egy firefoxtól és nss-től teljesen független dolog miatt engedélyeztem az updates-testing repót, másrészt mielőtt elfelejtettem volna, a prioritását nem állítottam be. A topicot átraktam a fedorás topicok közé, és fedje jótékony homály az idők végezetéig. :-S

Bővebben: https://blog.centos.org/2020/12/future-is-centos-stream/