1 host, 1 IP -> több VPS

-

( _ventura_ v | 2023. 04. 23., v – 18:25 )

Hogy legyen DE-m is, amivel jobb monitorozni.

Mivel monitorozol, hogy DE kell hozzá ?

Fedora 41, Thinkpad x280

Ez félreérthető volt. Munin-t szoktam használni.

Ha bármilyen gond van, akkor DE alatt rengeteg olyan grafikus tool van, amivel áttekinthetőbb sok minden. Ilyen pl a partíció kezelés. A realtime erőforrás felhasználás grafikonon (virt-manager ezt tudja) 

További pl.: Konsole alatt nem vagyok tab-okra korlátozva. Nekem kevés a 6 db tty. Tudom, ott a  screen. Nekem egy jó (K)DE sokkal hatékonyabb és produktívabb.

Én is öreg. :) 

Mindenhol azonos környezet nagyon produktívvá tesz.  Mivel ezt felismertem, már leszarom mi volt a trend 30 éve. Vagyis, hogy szerverre nem rakunk X-et és semmi felesleges programot. Akkor még rendszer felhasználóink voltak, akik potenciális támadói lehettek a rendszernek. Ma már ezek az appok, ha nem nyitnak kifelé portot, akkor nem gondolom, hogy veszélyt jelentenek. Mindemellett az egyetlen rendszerfelhasználó én vagyok, aki ráadásul kulccsal megy be ssh-n keresztül. Vagyis kifelé 22-es port nyitva, minden más proxyzva tovább. Egyetlen lokális támadó én lehetek.

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+Silver+4309Y+%40+2…

load average: 0,06, 0,07, 0,15

free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi       8,0Gi       114Gi        44Mi       2,7Gi       116Gi

( msandor v | 2023. 04. 23., v – 19:02 )

A virt-managert a menedzser gépen futtatom (laptop), ha igény van rá, ssh-n csatlakozik a hosthoz. Ezt is csak ritkán, az esetek 99%-ban elég egy konzolos "virsh valami" parancs.

amire en hasznalom hogy configban is meg lehet adni a jumphostot es akkor nemkell az ssh-nak. es ahogy a pelda is mutatja lehet alias-hostneveket is letrehozni. nekem is igy van, amikor mas-mas ssh key-et kell hasznalni. (az inkabb githez van)

Host foo.gitlab
  HostName gitlab.ceg.hu
  IdentityFile ~/.ssh/id_rsa_foo

Host bar.gitlab
  HostName gitlab.ceg.hu
  IdentityFile ~/.ssh/id_rsa_bar

ssh git@foo.gitlab

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( n.balazs v | 2023. 04. 24., h – 15:44 )

Pár javaslatom - tényleg csak pár, mert hosszú lenne a lista:
1. A host OS és a vm-k ne legyenek ugyanabban az IP tartományban. Legyenek izolálva egymástól ssh kulcs szinten is.
2. A host OS csak a virtualizációért feleljen. Ne legyen rajta se SMTP szerver, se Nginx. Tedd azokat külön vm-re.
3. A konfigokat tárold valami verziózható tárolóban. Ez lehet Git, de lehet akár Etckeeper is.
4. Authentikáció nélküli SMTP ne legyen. Sehol. Kifelé se.
5. A vm-eknek könnyen mozgathatóaknak kell lenniük másik hostra.
6. Nem látok VPN-t a leírásban. Gondolom ennek megvan az oka. Célszerű a nem publikus forgalmat VPN-be terelni a gépek között. Így kifelé csak tényleg 1-2 vm, 1-2 publikus szolgáltatással kell látszódnia (publikus weboldal, publikus SMTP szerver stb.).

1. Arra gondolsz, hogy a hoszt maszk /30 a VPS-ek mondjuk /27 ?

2. Opció az iptables is, de nem tudom mivel lennék előbbre vele. 1 IP van.

3. Ezt így szoktam.

4. Egy belső hálón, ahol csak a saját VPS-ek amiken saját appok vannak ez milyen kockázattal jár? 

5. Ez megvan.

6. Hoszton van egy Openvpn szerver, amihez én tudok csatlakozni. A VPS-ek között nincs. De oda minek? 

Kifelé csak a szükséges portok vannak nyitva amin a szolgáltatások üzemelnek.

 

 

Amúgy köszi minden észrevételt, mert elgondolkodtat.

1. szolgaltatok szoktak adni egy egyedi belso ipt+vpn kapcsolatot amivel elered ezeket a belso ipket. a host kapjon egy ilyet is. igy be tudsz maszni a hostra ha minden halott.

2. igen inkabb iptables, de megjobb lenne egy firewall vm (vyos, mikrotik, "kezi debian", akarmi), en arra raknam a sajat openvpnt. errol mar elered a hostot is napi adminolasnal.

 

ui: nezegess proxmox VE-t, meg PBS-t.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

1. A hosztra iDrac-on keresztül is be tudok menni.

2. A router VPS-nek adnád passthrough a hálókártyát? és onnan mennél ki a  hosztra?

 

 

Ez esetben, hogyan oldod meg a név szerinti irányítást?
józsi.hu 80/443 -> szerver1
béla.hu 80/443 -> szerver2
józsi.hu MX 465/993 -> szerver3
etc...

a router vpsen akar futhat egy haproxy, azzal el lehet "forwardolni". de ez az 1 ipt sem ertem. kb mindenhol lehet plusz cimeket kapni par ezerert, akkor lehet ip1 -> sajat, ip2 -> ceges, ip3 -> akarmi, stb csinalni. es problem solved.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

konnyebb hordozhatosag/visszaallitas: ha befosik a host (vagy host os), akkor csak siman ujrahuzod, berakod ala a vm-eket, es start. nalam pl a host os "sima" DOM modulon van (dellnek is van), az ssd/hdd-n a vm-ek cuccai. igy barmikor at tudom pakolni data diskeket vagy egy reszet masik gepbe.

haproxyval meg jobban tudod kezelni mi hova menjen: most csak ket fele kell szetosztani (mert a ceges gepen van minden virtualhostokban egyhelyen), de kesobb akar jobban akarsz szeparalni.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szerintem nagyon szakmailag közelíted meg, míg én a költségeket is számolom. Magamnak sem vagyok ingyen. Egy életem van. Ettől független jó olvasni, más gondolkodást is. Jelen pillanatban is sdd-k/hdd-k költöztethetők, csak kell eléjük egy proxy. Nem gondolom, hogy ez nagy ár. Nem látom technikailag az előnyét, hogy a stream  átirányítására használt technológia jelentős vagy érzékelhető előnnyel járna ebben a  rendszerben. Szóval úgy vélem kb mindegy, hogy iptables  vagy nginx proxy mögött van az apache és a vps. Sőt! Az nginx-nek van előnye is, hogy jobban cache-el, mint az apache. Annak is van előnye, hogy a vps-en Apache van, pl htaccess, rewrite.  Szóval amit csináltam az a tudásom és igényeim alapján készült. Mindenesetre érdekes más gondolkodást is megismerni. Nálam fontos mennyi a költsége a dolognak, és itt az idő a legdrágább. Amit te csinálsz ezzel a dom-mal az jó megoldás, de most nem ér annyit, hogy ebbe belemenjek. Jövőben biztosan, elgondolkodok rajta, azt már látom, hogy kell belőle meleg tartalék. Bevallom azt sem tudom, hogy az R450 tud-e bootolni SATA-ról vagy csak hotswap-es diskról (valószínűleg tud, de már nem lepődök meg ilyen korlátozásokon). 

 

ps.: a dom  jópofa, de egy újabb vendor locking

a dom egy sima sata eszkoz, ami oda tudsz kotni egy sata portra. kothetsz kulon ssdt is ra, ha van annyi ures fiokod. a szerver arahoz kepes fing osszeg.

es pont hogy a koltseg vagy ido azt amin sporolsz ha minden vmben fut, mert akkor hiba eseten csak a host rendszer kell telepitened, a tobbi mas minden keszen van (mert vagy a disken varja hogy ujra fusson, vagy visszallt backupbol).

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ma rákérdeztem a Dell DOM-ra  kereskedőnél. Azt mondta, hogy azok a nagyon régi Dell szerverekhez vannak, az újakhoz nincs már ilyen. Van egy olyan érzésem, hogy nem volt piaci siker a termék.

Megjegyzem, ha SW RAID-et csinálsz és rajta LVM-et, akkor mi abban a zavaró, ha az egyik lv a host? Ettől még diskek költözhetőek maradnak, max később ezt az lv-t dobot vagy újra használod másra.

1. Részben. Ne legyenek azonos VLAN-ban, sem IP tartományban Hoszt mondjuk 192.168.1.0/24, a VM-k meg 192.168.2.0/24.

2. Tudsz kérni 2. vagy 3. IP-t is szerintem.

4. Könnyebb felkerülni RBL listákra, mint lekerülni.

6. A VPN-nél én olyasmire gondolok, hogy mondjuk a cég telephelyén lévő szerver a hoszting cégnél lévő VPS-sel VPN-n keresztül kommunikálhasson csak. Ne kelljen portokat nyitogatni, titkosítatlan forgalmat kiengedni a netre még véletlenül se.

Láttam egy jó vagy inkább érdekes megoldást erre. Én nem csinálnám meg, mert nekem zavarja a szemem.

Céges háló 192.168.1.0/24 volt, egyik kliens egy router volt, aki szintén ezt a tartományt osztotta ki. Aki a routeren volt kliens, ha kettészakadt sem tudott IP alapon belátni a céges belső hálóba, mert a saját tartományát használta.

( Fisher v | 2023. 04. 24., h – 20:04 )

"Így miatta érdemes (muszáj!) a belső gépeket is https-en futtatni"

Biztos nem muszáj, és valószínűleg nem is érdemes. A WP_HOME és WP_SITEURL érdekes a wp-config.php-ban.

( kikadff v | 2023. 04. 25., k – 08:00 )

Tök jó, hogy belefért az egész a bevezető dobozba. Esetleg megpróbálhatnád máskor a cím mezőbe rakni az egészet.