- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Honor 400 - és mégis mozog a kép
- Telekom mobilszolgáltatások
- One mobilszolgáltatások
- Térerő gondok, tapasztalatok
- Na! Ez egy JÓ utólagos autós fejegység - Minix CP89-HD
- Samsung Galaxy A34 - plus size modell
- Új térképfunkciók érkeztek az Amazfit T-Rex 3-ba
- Google Pixel topik
- Nem várt platformon a OnePlus Nord 5
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Krystal_s
addikt
válasz
lev258
#30199
üzenetére
Pedig próbáltam azt is, pár sorral feljebb írtam....
A javaslatod ez volt:
"Terminálban próbálj meg valamit.
sudo rmmod iwlwifi
sudo modprobe iwlwifi 11n_disable=8"Itt pár sorral feljebb írtam, hogy:
"Amiket írtak pl sudo modprobe iwlwifi 11n_disable=8 és 2 egyáltalán nem segítettek."
A disable=8-nál teljesen eltűnt a wifi még a beállításokból is. -
inf3rno
nagyúr
válasz
Krystal_s
#30194
üzenetére
Hát nem kéne, hogy jobban szeresse a nagyobb távolságot. Ha ugyanúgy live linux-al próbáltad, akkor lehet, hogy hálókártya vagy antenna hiba. Az energiagazdálkodás is szóba jöhet, amit írtál, főleg ha valami laptopról van szó. Ha aksiról megy, akkor leveszi mindenről az áramot. Dugd rá hálózatra. UEFI/BIOS-ban is vannak beállítások energia gazdálkodásra, ahhoz is hozzá lehet nyúlni.
-
Frawly
veterán
válasz
Krystal_s
#30196
üzenetére
Nem tudom mi lehet a gond. Az rfkill üzenetből ítélve mintha le lenne tiltva a Wi-Fi valami gomb-bal fizikailag a gépen.
Próbáld meg feltelepített Linux alól, ha fent van a gépen. Úgy kivédjük ezeket az rfkill hibákat, és miután kapcsolódott az SSID-hez, jobban erre a csatornamódosításra, HT40+ vagy HT40- kapcsolóra tudunk koncentrálni, hogy az iw dew utána visszaadja-e a 40 MHz-es értéket. Mert most én úgy látom, hogy jelenleg így Live-on nem is tudja egyáltalán használni a Wi-Fi-t. Grafikus felületen tudsz csatlakozni, ahogy szoktál?
-
Krystal_s
addikt
válasz
Frawly
#30195
üzenetére
Ubuntu Live alatt vagyok. Ott elvileg nem kell jelszó, de azért csináltam, mert hibát írt ki.
ubuntu@ubuntu:~$ sudo passwd root
New password:
Retype new password:
passwd: password updated successfully
ubuntu@ubuntu:~$ su
Password:
root@ubuntu:/home/ubuntu# systemctl stop NetworkManager
root@ubuntu:/home/ubuntu# ip link set wlp2s0 down
root@ubuntu:/home/ubuntu# iw dev wlp2s0 set channel 11 HT40+
kernel reports: (extension) channel is disabled
command failed: Invalid argument (-22)
root@ubuntu:/home/ubuntu# ip link set wlp2s0 up
RTNETLINK answers: Operation not possible due to RF-killSuccessfully initialized wpa_supplicant
root@ubuntu:/home/ubuntu# iw dev
phy#0
Interface wlp2s0
ifindex 4
wdev 0x1
addr xx:xx:xx:xx:xx:xx
type managed
txpower 15.00 dBmValami nem jó, de most nem a 40 MHz lesz a gond, mert megnéztem úgy is, hogy a Routerben átállítottam 20 MHz-re és a csatornát is megváltoztattam. Sajnos akkor sem lett jó. Térerő továbbra is max, de a sebesség sokszor 1 Mbit/s, aztán 54, 134, random változik, instabil.
A leírások szerint a gksudo gedit /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
Code: wifi.powersave = 2
segítene, de mivel Live linuxon vagyok, ezért elvesznek a beállítások restart után.
vagy
Code: echo "options iwlwifi 11n_disable=8" | sudo tee /etc/modprobe.d/iwlwifi11n.conf Press Enter, give your password and press Enter again.
Reboot. -
Frawly
veterán
válasz
Krystal_s
#30194
üzenetére
Próbáld meg parancssor alól. Ha még mindig Ubuntu alatt vagy, ott bontsd a Wi-Fi kapcsolatot kézzel, grafikus menüből.
Majd nyitsz egy terminált, abba (kér root jelszót, meg a Wi-Fi eszköz neve lehet nálad nem wlan0 lesz, hanem wlp-akármi, és a channel sem 1 lesz):
su
systemctl stop NetworkManager
ip link set wlan0 down
iw dev wlan0 set channel 1 HT40+
ip link set wlan0 up
wpa_supplicant -B -i wlan -c <(wpa_passphrase SSIDd WPA2jelszó)
iw devAz utolsó parancs az utolsó előtti sorban írja a width-nél hogy hány MHz-en megy. Majd mérd le, hogy mennyivel megy, megvan-e az a 270 Mbit, amit akarsz. Esetleg ha a fenti parancsok nem segítenek, akkor újrabootolsz. A grafikus felületen megint bontod kézzel a kapcsolatot. Szintén terminálba ezt adod ki:
su
nmtuiEbben bekonfigolod a kapcsolatot, és kapcsolódsz. Nézd meg, hogy itt engedi-e a 20/40 MHz-et állítani. Ha kapcsolódtál az új beállításokkal, akkor iw dev paranccsal nézd meg terminálban, hogy átállt-e 40 MHz-re.
-
Krystal_s
addikt
válasz
inf3rno
#30193
üzenetére
Soha nem ugrál Win alatt. Nincs a közelben más Wifi, ami bezavarna.
Nincs meg a 270 sem, csak néha ugrik fel annyira. Most nézem jelerősség 100%, sebesség 1 Mbit/s, aztán 40...
Lementem a másik géphez. Ott stabilan 270 Mbit/s.
Nem értem mi lehet, x-akta. :/
Èn gépemben Intel Centrino Ultimate-N 6300 AGN van, a másikban Intel Centrino Advanced-N 6200. -
-
Krystal_s
addikt
válasz
inf3rno
#30191
üzenetére
Köszönöm.
Az előbb próbálgattam pár beállítást.
Windowsban látom mennyivel kapcsolódik. Amikor a sebességnél azt írja max 144 Mbit/s, akkor 20 MHz-en megy, amikor max 300 Mbit/s, akkor 40 MHz-en.
Ubuntu 20.04-et néztem... Sosem mutatott 300-at, csak max 270 Mbit/s volt, de az már 40 MHz-en megy.
Folyamatosan ugrál a sebességérték 1 és 270 Mbit/s között. (a jelerősség jó, itt van mellettem pár m-re a Router és Win alatt mindig stabil).
Lehet mégsem a sávszélességgel van a gond.
Úgy láttam kis időre javul a helyzet, ha tiltom a Power Management-et, de egy idő után újra nagyon ingadozik a sebesség 1-270 között.
Ez nem egyedi gond. Egy másik gépemnél (más router) másik Intel Wifivel is pont ez volt pár éve.
A neten rengeteg ilyen panasz van, de még a konkrét megoldást nem találtam meg.Amiket írtak pl sudo modprobe iwlwifi 11n_disable=8 és 2 egyáltalán nem segítettek.
sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
wifi.powersave = 2
elmentettem, de a rendszert nem restartoltam, mert Live... -
Vtmk
tag
Sziasztok.
Lenne egy kérdésem. Olyan gondom van,hogy tegnap még jó volt a szerveremről kérek le naponta többször egy fájlt.De ma valamiért 206-ot ad vissza válaszul. Másik fájl szépen lejön.
Most átírtam egy másik file nevét erre azzal letölti. xml.gz-ről van szó tartalmilag is jónak tűnik. Mi lehet a baj?
-
-
Van itthon egy EdgeRouter. Minden szep es jo, de miota o van a rendszerben, idonkent egy-egy Slack uzenet timeoutol - magyarul: a chat alkalmazas nem tud POST-olni a szerverre. Prohardveres fajlfeltoltesekkel is gond van neha.
Mi lehet ennek az oka? Otletem sincs, hova nyuljak (foleg, hogy nem determinisztikus).
-
bambano
titán
válasz
kovaax
#30174
üzenetére
mert a dhcp-nek is van késleltetése, lease time, meg a dns-nek is.
router nincs a rendszerben. switch van, ami nem tudja a szükséges funkciót.
dnsmasq sincs.viszont szöget ütöttél a fejembe, a debian bridge kódban lehet csodát tenni a mac címekkel... ezen még el fogok gondolkodni
kösz.
-
kovaax
őstag
-
kovaax
őstag
válasz
bambano
#30171
üzenetére
Miért nem? Hülye vagyok a hálózatos dolgokhoz, de valami ilyet képzelek el: a fontos nyomtató lóg a debianban levő második hálókártyán egyedül, és azon figyel csak a dnsmasq, aki mindkét hw címre ugyanazt az ip-t osztja ki dhcp-n, amit meg átenged a debian a "külvilág" felé. (Mondjuk első körben a routerben próbálkoztam volna én is, ha értenék hozzá.)
-
válasz
f_sanyee
#30170
üzenetére
Ha jól látom, akkor ugyanaz mindkettőnknek.
[root@hostname username]# cat /usr/lib/systemd/system/lvm2-pvscan@.service[Unit]Description=LVM2 PV scan on device %iDocumentation=man:pvscan(8)DefaultDependencies=noBindsTo=dev-block-%i.deviceRequires=lvm2-lvmetad.socketAfter=lvm2-lvmetad.socket lvm2-lvmetad.serviceBefore=shutdown.targetConflicts=shutdown.target[Service]Type=oneshotRemainAfterExit=yesExecStart=/usr/sbin/lvm pvscan --cache --activate ay %iExecStop=/usr/sbin/lvm pvscan --cache %iStartLimitInterval=0TimeoutSec=30Ami még feltűnt, hogy mintha a /var kétszer lenne felcsatolva:
Ez lehet gond vagy ez így normális? Ha nem, hogyan lehetne csak az sda2-ről leválasztani?
-
inf3rno
nagyúr
válasz
bambano
#30171
üzenetére
Nem vagyok benne biztos, hogy erre az egészre van tényleges igény. Mármint egy irodában azért előbb vagy utóbb mindenkinek világossá válik, ha nem megy egy nyomtató, és a másikra kell küldeni a nyomtatni valót. Utána meg pár lépéssel több, de ideiglenesen belefér. Ha valami program nyomtat, akkor meg gondolom az is kap valami visszajelzést, hogy sikerült e a nyomtatás vagy nem. És ha nem, akkor megpróbálhatja a másik nyomtatóval.
Tulajdonképp amit akarsz az az, hogy egy bizonyos porthoz legyen kötve az IP cím. Ezt tudják bizonyos managed switch-ek elvileg. Ez is alátámasztja [link].
Lehet még elé tenni egy gépet, CUPS szervert rátenni, és arra kötni a nyomtatót, pl USB-vel és úgy nyomtatni. Viszont akkor tök felesleges hálózati nyomtatót tartani.
Ezen kívül jogkör nélkül nem hiszem, hogy bárki bele tud nyúlni abba, hogy melyik mac address melyik IP címet kapja. Max még azt lehet, hogy a hosts fájlba írsz bele egy programmal vagy DNS szervert használsz.
-
bambano
titán
-
f_sanyee
senior tag
válasz
Fecogame
#30165
üzenetére
/usr/lib/systemd-ben nem érdemes változtatni, mert update felülirja.
Hogy néz ki a teljes file? Biztosan ezt használja?
systemctl status lvm2-pvscan@8:2.service Loaded sorban irja.nálam ilyen:
[Unit]
Description=LVM2 PV scan on device %i
Documentation=man:pvscan(8)
DefaultDependencies=no
BindsTo=dev-block-%i.device
Requires=lvm2-lvmetad.socket
After=lvm2-lvmetad.socket lvm2-lvmetad.service
Before=shutdown.target
Conflicts=shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/lvm pvscan --cache --activate ay %i
ExecStop=/usr/sbin/lvm pvscan --cache %i
StartLimitInterval=0 -
Krystal_s
addikt
Sziasztok, Linuxon (Ubuntu, Mint) hol lehetne átállítani a Wifi sávszélességet?
Az alap 20 MHz-et kellene 40 MHz-re, vagy autora állítanom, mert különben csak fele sebességgel megy net. 120 Mbit/s helyett 60.
Egyik gépben Intel Centrino Ultimate-N 6300 AGN van, a másikban Intel Centrino Advanced-N 6200.
A Routerben be van állítva a 2,4 GHz, 40 Mhz, de az nem elég. Windows alatt is át kellett állítanom, hogy jó legyen a sebesség. Alapon ott is 20 MHz volt.
-
bambano
titán
Mikrotik topicban kérdeztem, hogy hálózati megoldás van-e a következő problémára, nemigen volt. Tehát linuxos (debianos) megoldást tud-e valaki javasolni?
van két nyomtató, egy fontos meg egy nem annyira fontos, különböző helyen. ha a fontos nyomtató megdöglik, akkor a fontosat félrerakják, lekapják a nem fontosat és felrakják a fontos helyére. ennek a megoldásnak az a hátránya, hogy az ip címeket kézzel le kell cserélni.van ötletetek, hogyan lehet megoldani, hogy a nyomtató a helye alapján kapjon ip címet? vagy egyéb megoldás, hogy rendszergazdai segítség nélkül mehessen tovább a munka?
-
válasz
sh4d0w
#30164
üzenetére
Köszi!
Állítottam a service timeout-ját a
/usr/lib/systemd/system/lvm2-pvscan@.servicefájl végére illesztve a TimeoutSec értéket beállítva, így:
[Service]Type=oneshotRemainAfterExit=yesExecStart=/usr/sbin/lvm pvscan --cache --activate ay %iExecStop=/usr/sbin/lvm pvscan --cache %iStartLimitInterval=0TimeoutSec=30Kellene ezen felül valamit még beállítanom? Az újraindításnál ugyanúgy megakadt a process, viszont ezúttal ennél a sornál:
blkdeactivate: [SKIP]: unmount of vg00-var (dm-2) mounted on /var -
-
válasz
f_sanyee
#30162
üzenetére
Csak ennyit ír ki összesen:
May 05 10:24:34 hostname systemd[1]: Starting LVM2 PV scan on device 8:2...May 05 10:24:35 hostname lvm[519]: pvscan[519] VG vg00 skip autoactivation.May 05 10:24:35 hostname systemd[1]: Started LVM2 PV scan on device 8:2./var/log/boot.log és annak a dátumozott változataiban rákeresve sem ad ki több infót a 8:2 azonosítójú meghajtóra.
-
Egy furcsa problémával szembesültem az egyik (nem általam felépített, csak megörökölt, céges) VM-en. A reboot folyamat során a gép nem tud újraindulni, ugyanis a /var/log/messages alapján az alábbi sornál elakad:
systemd: Stopping LVM2 PV scan on device 8:2...Megnéztem a 8:2 jelzésű meghajtót melyik lesz, és egy pontosan ugyanolyan LVM, mint bármelyik másik:
Mi lehet a gond? Hogyan lehetne ezt a hibát kiküszöbölni?
A gépen CentOS 7.8 fut.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30156
üzenetére
Szerintem felesleges. Annyira nem lehet bonyolult a logikája, hogy egy arduino ne bírná el. Egy HTTP szerver is olyan, hogy simán elviszi. Ha loggolni akarod a szenzor adatokat, és feldolgozni, ahhoz esetleg kell valami komolyabb egy ilyen adatbázissal: [link]
Milyen poén lehet úgy enni valamit az asztalon, mondjuk egy kis tepsis fűszeres burgonyát, hogy a krumpli a saját biokrumplink, amit a kütyük neveltek fel, az ubisali uborkája és fokhagymája dettó, paradicsom, stb. minden az asztalon az "üvegházból" van
Csak aztán a végén nehogy ide lyukadjunk ki
"Vannak mezők, végtelen mezők, ahol az emberek többé nem születnek. Tenyésztenek bennünket. Sokáig nem akartam elhinni, de aztán saját szememmel láttam a mezőket. Láttam, hogyan cseppfolyósítják a holtakat, hogy intravénásan táplálhassák az élőket."
-
Dißnäëß
nagyúr
válasz
inf3rno
#30154
üzenetére
Hááát maradok a saját nyelvén, valami Processing vagy mi, jó lesz az, nem egy nagy rakétatudomány ahogy elnéztem. Egész érthető. Csak kéne egy induló szett
PoE jó dolog, rahedli kis Arudino kütyüt elbír egyetlen kábel, de valszeg valami ultraolcsó kis wifi modullal oldom meg, így egyetlen kábellel végig tudok menni áramellátást illetően a kütyük hadán sorosan, nem kell switch-ből kiindulva csillagpontosan húznom mindenhova 1 tyúkbelet. Előbbi esetben kell a wifi az adatátvitelhez, utóbbi esetben meg PoE miatt magára a kábelre tehetem rá az adatot is, de inkább wifizek, még a többlet költség ellenére is. Szerintem tálcánként - de majd kiadja úgyis a tényleges projekt - elég lesz 1 kisebb Arduino kontroller a "cserepekbe" tett szenzorokat figyelni, de majd meglátom. Jó kis hókamókák ezek. Milyen poén lehet úgy enni valamit az asztalon, mondjuk egy kis tepsis fűszeres burgonyát, hogy a krumpli a saját biokrumplink, amit a kütyük neveltek fel, az ubisali uborkája és fokhagymája dettó, paradicsom, stb. minden az asztalon az "üvegházból" van Nagy álmom így élni. Egyszeri nagyobb költség, de aztán évekig nyugi van. Egy RPi-re már kellene mindig OS frissítés, ez, az, amaz, az Arduino kellően buta ahhoz, hogy 20 év múlva is csinálja ugyanazt, amit ma, zéró logic. Bár egy mai Pi is elvan, de azért ott az OS mégiscsak egy Debian rajta, logolgat, kicsit önállóbb életet él, tényleg nem egy olyan eszköz, amibe beleírod a programot és elvan míg szét nem esik. De tuti lesz Pi is a rendszerben, de szerintem ő csak a fej lesz majd. -
inf3rno
nagyúr
válasz
Dißnäëß
#30152
üzenetére
Pedig elvileg megy arduino-val is a nodejs. Az elvadultabbak ESP32-vel tolják az ilyen szenzorozást, de az a nagy baja, hogy nincs olyan változat, amin normálisan meg van oldva a POE, úgyhogy két vezetéket kell vinni, meg gondolom valami egyenáramú rendszert is kialakítani. Lehet wifi-vel is, de az megdobja a villanyszámlát gondolom, és bár alacsony a fogyasztása, de ha 100 ilyen kütyüt kiteszel, akkor azért már tud villanyszámlát generálni. Amúgy pont ilyen üvegházas projekthez néztem őket én is. Mindketten lusták vagyunk öntözni asszem.
Az elektronika engem is érdekel, de még nem ástam bele magam. Nagyjából az a végcél, hogy értsem, hogy hogyan működik egy számítógép, egy oprendszer, meg rajta mondjuk egy nodejs, plusz ugye a hálózati kommunikáció. Ez azért legalább egy évtizedre elég anyag szerintem. A mikrokernel azért izgi, mert annál olyan 10k sor a kernel, és azt egy átlagos programozó azért még képes átlátni. Persze ami máshol a kernelben van, az mind kimegy alkalmazásnak, de egyszerűbb így leszűkíteni a minimumra. Pl ha egy hello word-ig eljutok soros porton keresztül az már fincsi, Utána lehet mókolni tovább hálókártya driverrel meg videokártya driverrel, meg ilyesmikkel. Az arduino sem áll olyan nagyon messze ettől. Lehet, hogy mikrokernelezésre veszek egyet, mert a szerver gépet teljesen más célra szánom. Meg egyébként is jobb, ha egy arduino füstöl el, ha valamit elcseszek, mint egy drága gép.
Ja hát nekem most egyelőre a UPC-nek a routere van itt, úgyhogy nem tudok belenyúlni. Ha kimondottan indokolt lenne, akkor vennék valami Asus-t és menne rá a WRT, de most még nem érzem szükségét, és a pénzt meg nem akarom annyira szórni.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30150
üzenetére
Úgy van, ahogy a kolléga mondja, határvédelemben kopog az ember.
Kicsiben privátban én is NAT mögött vagyok, van egy olyan-amilyen iptables script-em mégis a linux host-omon, de ennyi. Ha Kína bejönne a Netflix-en keresztül az okostévébe és elkezdené törni a gépem, ne essen el azonnal, kicsit megnehezítem a dolgukat (pár perccel)
Viccet félre, paranoidnak lenni mindig jó és hasznos.
Tanulás: én most meló mellett próbálok tanulni annyi mindent, hogy nem győzöm
Elektronika, frontend, node.js és régi dédelgetett álmom, az Arduino. Akarok egy vagy termőföldes, vagy teljesen hidropónikus minifarm projektet építeni vele, talajnedvesség szenzorokkal meg minden pittyputty-al és mindig azon kattogok, hogy ha már node-ot tudok, akkor miért nem Raspberry Pi-zek, de rájöttem, hogy nem kell nekem OS ahhoz, hogy alap tökautomatizált rendszert építsek fel, ami bekapcsolás után pár mp-el már működik is és ha 20 évig nem update-elem, akkor sem történik semmi. Egyszerű, igénytelen, teszi a dolgát. Szóval maradok az Arduino-nál és majd valamiféle aggregált módon állok hozzá az egészhez, hogy 1 Arduino több szenzort visz, az őket begyűjtő és vezérlő Arduino-k (nem sok) pedig végül befutnak 1 Pi-be mondjuk. Hát ez is egy hosszú út, de legalább látom értelmét. Próbálok mostanság olyat csinálni, aminek van is értelme, nagyon elvesztem az elmúlt években haszontalan dolgokban. Mikrotik lett volna még, de azt is annak gondolom, pedig piszok jó cucc, de többet hoz nekem real-life-ban egy raklap itthon termesztett zöldség, amit automatán öntözök és monitorozok + figyelmeztet egy naptár funkció, ha megérett "aratásra", mint az, hogy most milyen router oszt nekem egy netet. Sajnos egy nap még mindig csak 24 órából áll 
-
inf3rno
nagyúr
válasz
Dißnäëß
#30148
üzenetére
Szerintem az alapelvek ugyanazok lehetnek mindegyiknél. Egyszer kell megtanulni, utána meg elég beleolvasni a manual-ba. Én most éppen a microkernel-es operációs rendszerekbe vagyok belezúgva, azon belül is vannak nagyon érdekes projektek: [https://en.wikipedia.org/wiki/MINIX] https://en.wikipedia.org/wiki/L4_microkernel_family https://github.com/seL4/seL4 https://github.com/kernkonzept/l4re-core https://github.com/chrissicool/l4openbsd
https://genode.org/download/sculpt Úgyhogy van mit olvasgatni. De kb. úgy működök, mint egy processzor, csinálok valamit egy ideig, aztán ha megunom, akkor átváltok egy másik folyamatra, úgyhogy előbb vagy utóbb ez a tűzfalazás is sorra fog kerülni. -
Dißnäëß
nagyúr
válasz
inf3rno
#30144
üzenetére
Látom jó kis egészséges vita alakult ki REJECT és DROP körül az általad linkelt fórumon.
man iptables -ben a REJECT target írója Jozsef Kadlecsik, lehet elő tudnád ásni az arcot, ha utánajárnál. Nála lesz olyan infó, ami ÚGY VAN és 100% hihető, feltételezem (ha 1. a Netfilter csapat tagja, 2. ő írta a REJECT-et).De amúgy meg azt is látom, hogy az iptables is kifutó lassan, itt az nftables helyette: [link]
Picit más szintaktika és logika, de többet tud + teljesítményben is jobb. Lehet érdemes lenne erre felülni, mielőtt túlzottan kitanulod az iptables-t. (Én meg ipchains-el szívtam anno sokat és iptables-ön tanultam. Nem kell egyik a másikhoz, most sem kell iptables mester lenni, hogy nftable guru legyél.. ha már kézzel írogatunk)
. -
inf3rno
nagyúr
válasz
Fecogame
#30141
üzenetére
Ránézésre ez ennyit csinál, a többi meg körítés:
iptables port_scanners hash:ip family inet hashsize 32768 maxelem 65536 timeout 600
iptables scanned_ports hash:ip,port family inet hashsize 32768 maxelem 65536 timeout 60
iptables INPUT -m state --state INVALID -j DROP
iptables INPUT -m state --state NEW -m set ! --match-set scanned_ports src,dst -m hashlimit --hashlimit-above 1/hour --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name portscan --hashlimit-htable-expire 10000 -j SET --add-set port_scanners src --exist
iptables INPUT -m state --state NEW -m set --match-set port_scanners src -j DROP
iptables INPUT -m state --state NEW -j SET --add-set scanned_ports src,dstAzért én óvatosabb lennék a helyedben az ilyen scriptekkel, mert ezzel gyakorlatilag átadtad az irányítást a géped felett a script írójának [link] Aztán erősen bízol benne, hogy a következő release nem támadókódot tartalmaz.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30140
üzenetére
Köszi! Igy már jóval világosabb. Erre a DROP témára rákérdeztem egy Q&A oldalon, hátha tudja valaki a választ. Ha nem, akkor majd kipróbálom az itthoni szerveren. Egyelőre most nem Linux van rajta, úgyhogy az iptables nem játszik, de szerintem van valami alternatíva, amivel meg lehet csinálni ugyanezt.
-
bambano
titán
válasz
inf3rno
#30138
üzenetére
"Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat.": ha előbb accepteled az establishedet meg a relatedet, és utána dobálod el a synt, akkor nem záródik be.
"csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni.": ez önmagában igaz, csak kopogtatást nem így csinálnak. a szekvencia részeit képző portokra nem kell forward, ugyanúgy dropolod, mint a többit, csak másik ipset-be jegyzed fel.
-
válasz
Fecogame
#30141
üzenetére
Tegyuk fel, hogy en
- nem valtoztatom meg a portot
- nem hasznalok fail2ban-t
- nem hasznalok portscan protectiont
- csak kulccsal lehet bejonniEz milyen szempontbol kevesbe biztonsagos, mint a te felallasod?
(Production kornyezetben mondjuk nincs is publikus IP cime azon szervereknek, ahol a cuccok futnak.)
-
Nálam ennyiből áll az SSH védelem:
- Default portszám megváltoztatva (50000 feletti)
- Portscan Protection
- root felhasználó nem tud belépni, azon kívül is csak egy, teljesen másik usernevű
- 50 karakteres jelszó (kisbetű, nagybetű, szám)
- Fail2ban + aki root-al próbálkozik, azonnal ki van tiltva egy hétreHa ezen valaki átjön, egészségére
-
Dißnäëß
nagyúr
válasz
inf3rno
#30138
üzenetére
A második felvetésedre: hááát ez jó kérdés, iptables-ben (vagy még az elődjében, ipchains-ben) volt anno olyan target, hogy REJECT, talán ma is megvan még akármilyen okok miatt, na az viselkedik úgy, hogy elutasításkor visszajelez, hogy "ide nem jöhetsz be" , aminek puszta megtörténte miatt elárulva, hogy ott van gép, port, szolgáltatás, amit lehetne törni. Az akkoriban erre válaszul hozott DROP target már olyan végződtetés, hogy onnan semmi infó nem megy vissza a küldő fele, szóval mintha fekete lyuknak beszélne, DROP esetén nemigen tudja megállapítani, van-e ott valami vagy sem. Még TCP SYN dolgokkal bohóckodhat, de mindenre fel lehet készíteni egy gépet úgy megcsinálva, hogy távolról isten se mondja meg, hogy ott van valami az adott ip címen, hacsak nincs fizikai hozzáférése a network-höz.
Első felvetésed:
Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.
Az, hogy egy port nyitva van-e, egy dolog. Arra is kihatásunk van, MIRE van nyitva. Egy nagyonegyszerű csecsemőbiztos példa most így fejből gyorsba, a teljesség igénye nélkül, csak az INPUT chain-re fókuszálva (pedig egy korrekt tűzfalban az OUTPUT is szűrve van, legalábbis akkor, ha magáról a tűzfal gép védelméről beszélünk.. ha a többiekéről, akkor meg a FORWARD mindkét iránya nat mangle és egyéb táblákban is, felhasználástól függően).Tehát egy marha primitív kézi fal arra a host-ra, amit védeni akarunk, és egy SSH-t beengedünk. Illetve a mi saját kimenő csomagjaink visszatérő lábát is
különben semmit nem lehet erről nagyon csinálni azon kívül, hogy egy buta SSH kiszolgáló.
iptables -X
iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPTÉs akkor a vastaggal emeltet lehet (igazából erősen illik) cizellálni, hogy source-ot adunk neki, egy adott ip-t vagy ip régiót, satöbbi.
Kérdésedre a válasz a state-ekben rejlik, azaz a 22-es port knocking alatt csukva marad NEW csomagok számára, de természetesen ha egy másik host már sikeresen bekopogott oda és kapcsolódva van, őt egy RELATED,ESTABLISHED szabály beengedi, ami generalizáltan, minden protokollra és minden source/destination portra értelmezve van. (Ezért nem szoktam használni ebben a formában, csak szűkítve, de akkor hasznos).
Ha csak 22-es portra akarunk kétszintű definíciót, ami beengedi a már felépült SSH-k visszatérő lábait, de újakat nem enged be korlátlanul:
iptables -A INPUT -p tcp --dport 22 -m limit --limit 10/s -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPTEz minden 22-es portra érkező ÚJ kérést úgy enged be, hogy csak másodpercenként 10-et enged ebből, a többit dobja. Minden új kérésre érvényes, de csak újakra. Az alatta levő sor pedig korlát nélkül enged minden 22-es portra beeső SSH csomagot, aminek van egy korábbi kimenő párja a táblákban már, így ha egyszer kapcsolódott valaki, egy SSH fájlátvitel sem okoz limit miatt gondot, bármennyi csomaggal korlátlanul kommunikálhat az sshd-vel.. szóval RELATED,ESTABLISHED lábakat nem szokás (vagy csak nagyon paranoid esetben) limit-el ellátni, burst-re is ügyelve de arra most nem térek ki.
A port knocking NEW-ra értendő, hiszen nem egy korábban kiment csomagra adott válaszcsomag az, ami érkezik és kopogna be, hanem új csomag, amolyan azonosítatlan, követés nélküli akarna bejönni. Őt csak számolni kell, mint kopogásszámot, de dobja is DROP-ra, míg a szekvencia nem teljesül, ergo nem lesz kimenő lába, mindig minden "kopogó" csomag NEW-nak minősül.
Ha ezen dimenzió mentén nézed, máris nem lehet azt mondani, hogy nyitva egy port vagy zárva: van, amire nyitva, van, amire limitáltan nyitva és van, amire zárva.
A limit egyébként hasznos, de érdemes a burst-öt is definiálni az elején, illetve tudni azt, hogy ha a szabályban definiált limitet pont egy hülye bot, vagy akármi lezabálja, Te sem jössz be már
Csináltam egyszer olyat, amikor egy hobbigépem törni akarták (még kezdő szöcske koromban, amikor 22-esre tettem ki SSH-t a nagy világhálóra), hogy láttam a logokban a millió jelszópróbálkozást, auth-ot, úristen mondom mivanitt, bruteforce indult ellenem
és úgy döntöttem, teszek 22-es portra NEW próbálkozásokra egy 3/m limitet, azaz 3 próbálkozás / perc, utána csőváz mindenkinek.1x tudtam belépni, utána kvázi örökre kizártam magam, mert a percenkénti 3-at elérte a próbálkozások száma a botok által, a fal zárt, én meg ugyanúgy kint maradtam egy putty zárás és újranyitás után
Szóval mindenre a limit sem megoldás, de mondjuk túlterhelések ellen egy egészséges mérték beállítása jó lehet, ami azon képzeletbeli határ felett van, ahányan akarnak oda jönni amúgy, botokkal együtt. Meg általában ezek a zombi gépek, botok, akármik többnyire 22-es porton kopognak, tehát ha a 22-est vagy az sshd-ban, vagy iptables-en keresztül nem 22-re rakod ki a publik interfészen, hanem valami tökmáson (1024 felett lehetőleg), az sokat segít. (Persze ne híres port legyen lehetőleg). SSH esetében úgy tudom kell induláskor a root jog, de egyébként ha most IRC szervert vagy akármi egyéb alkalmazást akarnál kitenni a netre, mindenképp 1024 fölé érdemes tenni, mert 1024-es alatti portokhoz root jog szükséges, azt meg nem akarjuk odaadni minden processznek (hacsak fel nem vesz utána nobody-t stb, de az megint más tészta). Azt vettem észre mindenesetre, hogy 22-ről ha elviszed SSH-t bármilyen módszerrel is, drasztikusan lecsökkennek az auth próbálkozások számai. Ez még nem jelent semmit, csak plussz háttérinfó, könnyítünk az sshd lelkén kicsit
Knocking esetén a NEW próbálkozások számát kell nézni, nem a RELATED,ESTABLISHED-eket, értelemszerűen. Utóbbiakból másodpercenként irdatlan sok jöhet és kell is bejönnie, lásd fájlátvitel, így a már felépült SSH kapcsolat nincs elkaszálva. NEW-val meg kopogjanak bátran, akinél teljesül, az eljut a szent grálhoz
-
#68216320
törölt tag
Sziasztok. Észrevettem az nginx esetében egy warn-t. Működés rendben, de valamiért az nginx -t command-ra az alábbi warn-t kapom:
$ sudo nginx -t
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulAz nginx-selfsigned.crt megtalálható és benne van egy kulcs. Valami probléma van ezzel a kulccsal? Vagy ez csak arra utal, hogy saját magam által aláírt tanusítványt használok és ez a baja? Certbot esetén rendbejönne?
-
inf3rno
nagyúr
válasz
Dißnäëß
#30061
üzenetére
"alapból úgyis zárva az SSH (példánál maradva) és port knocking-al, kopogtatva lehet kinyittatni azt ideiglenesen a host-al, az adott beérkezônek"
Nem teljesen világos, hogy ez alatt mit értettél. Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.
Ahogy nézem elképzelhető, hogy ez az iptables-es mókolás sem véd port scan ellen:: [link] Legalábbis azt írják, hogy úgy válaszol ezeknél a DROP-oknál a szerver, hogy azt mondja, hogy a szolgáltatás a port mögött éppen nem elérhető. Tehát annyi információ szivárogni fog, hogy melyik port mögött van szolgáltatás, de hozzáférni nem tudnak, ha nem ismerik a kopogási szekvenciát. Ebből viszont már tudnak következtetni arra, hogy kopogni kell, és vannak már botok arra, hogy brute force-al végigpróbálják. Arra jó, hogy még egy réteget beteszünk biztonsági szempontból az SSH fölé, de messze nem rejti el teljesen a szolgáltatásainkat és nem feltörhetetlen.
Tulképp ha a fenti igaz, és csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni. Azt hiszem rászánom majd az időt, hogy demonstráljam. Egyelőre most vannak fontosabb dolgaim.
-
Vtmk
tag
Sziasztok
Szeretném módosítani az urllib2.pyo-t. Meg is történt,de írás védelem miatt nem tudom visszamásolni. Ebben szeretnék segítséget kérni. Köszönöm
mount -o remount,rw /usr/lib/python2.7
cp -R /storage/downloads/urllib2.pyo /usr/lib/python2.7/urllib2.pyo
mount -o remount,rw /usr/lib/python2.7
mount: can’t find /usr/lib/python2.7 in /proc/mountsCoreelec 9.2.2 rendszer egy X96 MAX Plus Amlogic S905x3 Android 9.0 4GB/64GB DUAL Gig LAN set top box-ra van telepítve.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30114
üzenetére
Még annyit, hogy nagyon figyelmesen olvasd el stopperos összefoglalóját, amit linkeltem előzőben. Arany
Lesz benne érintve memória is, struktúra is, minden ilyesmi.Nem ez lesz az első 1-2 pool-od ma megkreálva, ami életed legjobban agyonoptimalizáltja lesz
de nem elméleti fizika azért. -
Dißnäëß
nagyúr
válasz
inf3rno
#30112
üzenetére
Így van, csak dedup, amit ritkán ajánlanak hogy használva legyen, totál felhasználásfüggő. Legalábbis ZFS fronton a "földi halandó" ne dedup-al kezdje. Egy médiafájlokat tartalmazó fájlrendszeren, ahol - feltehetően - nincs két egyforma fájl, se alatta lévő blokk, meg úgy semmi sem, teljesen felesleges és memóriafaló. Compression szintén nagyon függ sokmindentől, be is lehet kapcsolva (úgysem tömörít pl. már eleve tömörített fájlokat, lásd megint a híres média fájlok, FLAC-ok, mkv-k, stb), de nálam pl. a fontos fájlokat és vegyesbazár mindenfélémet tartalmazó mirror-on be van kapcsolva, míg a nagy médiafájlokat tartalmazó raidz-men kikapcsoltam már kreáláskor (ez kihatással van nem csak a puszta tényre, hogy tömörítve van-e adat, hanem arra is, hogy a blokkméretek fixek, vagy változóak). ZFS fine tune-ról külön könyvet lehetne írni, ezt sokan mondják és én is így látom.. nagyon mélyvíz és nagyon eltérően viselkedő megoldás ahhoz, hogy csak úgy általánosan egy skatulyába téve kijelentsünk róla dolgokat úgy, mint egy ext4-ről mondjuk. De a generalizálással mindig is gondja van az emberiségnek, törekszik mindenki az egyszerű dolgokra, na a ZFS nem az
De öröm az ürömben, hogy default beállításban is egész vállalhatóan műxik és amire létre lett hozva, az adat integritás garantálása, arra hibátlan. (1 lemeznél tudja jelezni a hibát, 2 vagy több esetén egy raid felállásban már korrigálni is). Az említett COW is fura így megemlítve, ugyanis a zfs alapból cow-s, ez a default másik jellemzője (ezért is SSD barát, ZOL TRIM támogatás hiánya ellenére - de már dolgoznak azon is). Meg nem csak fájlrendszer, hanem logikai kötetkezelő is egyben, kicsit LVM szagú. Dedup nélkül a zfs nem eszik sokat, csak valamivel többet, az ARC miatt (is), de az pl. paraméterezhető, ha a default beállítás nem tetszik, viszont dedup nyilvántartó táblák komplett kiesnek a képletből, default install és használat, pool/dataset creation esetén sincs bekapcsolva, jobbnak látta mindenki ezt off-ban tartani, enterprise felhasználásban egy (vagy több) dedikált storage admin ember már feltehetően még nálunk is jobban tudják, mit csinálnak és miért, ha szakértői a ZFS-nek és bekacsolhatják a dedup-ot.
ZFS-ről csinált egy marhajó összefoglalót stopperos fórumtárs, [link] , aminek már megírtam egy 2., gyakorlati részét jómagam, majd hamarosan publikálom talán. Lesz benne kicsiben is, VM-ben elpróbált játékok, meg a saját nagyobb példám is. Valamikor..
Nálam itthon 24 terányi diszk van különféle konstellációkban ZFS-re befogva, eddig nagyon elégedett vagyok vele. Nemsokára jönnek a cache drive-ok is, két enterprise grade SSD személyében, szóval egy egész pattogós házi storage motyó áll össze, de most sem panaszkodom. Talán idén át tudom a mostani workstation PC-met konvertálni egy igazi komoly storage vassá, egy új rack házikóban, ez még a jövő zenéje.
Az ARC mérete általában a rendelkezésre álló RAM /2 -ig mehet max, nálam most reggel óta van bekapcsolva a gép és 32G RAM-ból 5.76G foglalt, ebből a linux szerint 1.5G a buffer/cache és mérete a ZFS-ről történő olvasás és ráírás ellenére nem látszik változni perpillanat.
-
-
bambano
titán
válasz
I02S3F
#30121
üzenetére
nem hiszem, hogy indokolni kellene
minden plusz, amit a védelem kedvéért teszel, segít.
ráadásul a fail2ban nem csak ssh-hoz jó, hanem levelezéshez, web cuccokhoz, meg sok más mindenhez is.kellően alacsonyra véve a limiteket, ad védelmet a próbálkozások ellen. pl. ha 3 rontott próbálkozás után repül az ip cím, de nem 5 percre, hanem mondjuk 8 órára, az segít.
értelemszerűen abból a nézőpontból, hogy kizárólag fail2ban-ra alapozni a védelmet, jogos lehet a kritika.
persze én, mint internet szolgáltató rendszergazdája, én csak a logjaim alapján tudok vitatkozni, mások érzelmeiről nincs objektív infóm.
-
- ha nincs jelszavas bejelentkezes, es a privkey nem kerult ki, akkor probalkozhatnak vegtelensegig az ssh-val, nem fognak bejonni
- ha gyenge a jelszo, es tenyleg be akarnak jonni, akkor be fognak jonni
- ha csak szokasos botnetes scan van, akkor kiprobalnak 30, 50, 100 jelszot, es utana mennek a fenebe (de egyebkent is tobb IP cimrol fognak jonni)... cserebe +1 konfiguralando szolgaltatas, es rossz esetben pont akkor zarod ki magad, amikor nem kene
Tehat az az info kellene, h a fail2ban miert ad plusz biztonsagot, mi ellen ved. Mert szerintem nincs olyan realis tamadasi vektor, ami ellen a fail2ban hatekony. Cafoljatok meg.
-
inf3rno
nagyúr
-
Frawly
veterán
válasz
bambano
#30111
üzenetére
Ezt nem tudtam, hogy az is ott van a kernelben. Akkor lehet kipróbálom azt is. Én eddig úgy tudtam, hogy a Xen-t külön fel kell telepíteni.
(#30112) inf3rno: ezt teljesen jól tudod. De ha már VM-ben próbálgat valaki, akkor valós szimulációként próbálkozzon, és maradjon a dedup, cow, tömörítés, mindenféle redundancia stb. bekapcsolva. Ahogy kikapcsolgatsz mindent, meg ilyen minimalista ideálkörnyezetben próbálkozol, az nem fogja visszaadni, amit majd a valóságban tapasztalsz.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30106
üzenetére
Én úgy tudom, hogy dedup-hoz kell csak sok memória hozzá, ha azt kikapcsolod, akkor egész szolidan eszik. De még csak tanulom ezeket a fájlrendszereket. Esetleg tudnál írni valamit a tényleges memória használatáról a zfs-nek, btrfs-nek, ilyesmiknek pl ext4-hez képest?
-
Frawly
veterán
válasz
bambano
#30109
üzenetére
Nekem meg elsőnek a KVM. Xen csak akkor, ha nem akar valaki még host OS-t is telepíteni, meg konfigurálgatni. De teljesen jó a KVM, nem kell semmilyen extra virtualizációs szoftver, pláne nem fizetős. Ott a KVM a kernelben, azt lehet használni QEMU-ban, tökéletes kombináció ilyen tanulásra szánt VM-ekhez, még a VT-x, VT-d is támogatott benne, ha a gép is támogatja, akkor simán megy.
A Hyper-V-t kipróbáltam anno sima desktop Win10 Prof-on, 64 bitesen, 2. gen i7-es laptopon, hát, lomha, lassú fosch az egész, de a MS-tól nem is vártam mást. Akkora overheadje van, mint az állat (ThinkPad X220 i7-2620M + 16 GB RAM mellett próbáltam). Ezt max. az ellenségemnek ajánlanám. Ha Windowson akar valaki hobbi VM-ezni, akkor VirtualBox, ha az nem tűnik elég stabilnak a feladathoz, akkor VMware Workstation ingyenes verzió.
(#30106) Dißnäëß: de én pont azt mondom, hogy én nem fukarkodnék, ha már virtuális gép, főleg szerver (vagy nem szerver, de valami modern desktop OS), én alapból min. 4GB-ot adok neki RAM-nak, és min. 2 prociszálat. Ezeket emelem is, ha szükséges, mert nem fut kielégítő sebességgel. 1 szál, meg 1 GB RAM nevetséges, annyit max. ilyen retro Win9x-es virtuális gépnek adnék, esetleg WinNT4, Win2k-hoz, de már utóbbiakhoz is belőnék 2 szálat, mert tudják kezelni.
-
kraftxld
félisten
válasz
Dißnäëß
#30106
üzenetére
Ha ilyeneket tesztelsz akkor én ebben a sorrendben próbálnám a virtualizációs cuccokat:
1, ESXi
2, VMware workstation Linux alatt
3, Hyper-V (tudom eretnekség ebben a topicban, de erre a tesztelésre teljesen jó és elég kicsi az overhead-je)Nekem egy ezer éves Lenovo T430s-em van és 2-3 VM simán elmegy VMware workstation-el.
-
Dißnäëß
nagyúr
válasz
Frawly
#30104
üzenetére
Ezt itt és most azonnal megvétóznám, egyrészt így tanultam ki magam is a zfs-t anno, mielőtt élesben elcsesznék valamit, (nem, nem kell alá tenger memória, a közhiedelemmel ellentétben), másrészt 1 szem vCPU-val és 1-2G RAM-al simán lehet php-zni, node.js-ezni és megannyi akár architekturális, akár backend és middleware fejlesztést és szimulációt csinálni. 8G RAM mellett ne mondd már, hogy nem tud az ember lecsípni némi RAM-ot és valami hasznosat alkotni, mert most azonnal magamhoz nyúlok
és neeem akart megfulladni semmi, hogy nincs alatta 100 CPU mag..Szerintem kicsit bőkezűen osztod az erőforrásokat, vagy csak nagyon egy irányba akarsz lőni ágyúval verébre. Értem én a nagyszerveresdit, de azért van a lónak túloldala is (ezt leírtam) + nyilván ki milyen jól lovagol, e kettő között még rengeteg lehetőség és tudnod kellene, melyik fázisban vagy éppen.
De egy webshopot, egy társkeresőt (nem azt, de hasonlót, mindegy), egy mittomén milyen dolgot, sok-sok egyéb komoly pénzcsináló projektet simán összerakok egy ilyen laptopon, egyet meg konkrétan a haverommal közös cégünknek rakott össze egy külsős fejlesztőbrigád és az egész motyó elfutna ezen az említett laptopon lazán, legalábbis a mostani 30-40 user-el (ha felfutott, az egy más téma, de itt már nem is csak DEV, hanem egyenesen UAT-ról beszélek).
Egy BSS stack-et már nem rakunk össze ezen, az igaz. Meg számlázórendszert sem, meg SAP gigainterfészeket sem. De az azért pont a ló túloldala, meg az ágyúval griffmadár kategória, itt most verébről volt szó végig.
És de, pont az InnoDB HA a másik, amit itthon teszteltem ki és paramétereztem mikor hogyan szénné, 3 kis VM-ben, előtte meg próbálgattuk a cégben még anno három másik soványka VM-en szintén, úgy kellett sírni a kapacitásért... de az MSSQL a másik akkor, ne csak szerencsétlen MySQL legyen mindig, itt sincs semmi dráma 3 ekkora VM-en egy Always On-t összelökni. Nem egy nagy sztori az egész, sem erőforrásban, sem konfigolásban, de igen, 3 csöpp VM-ben is elindul és tesztelhető, így tettük mi is. Tudod, írtam is, hogy PROD-ra semmiképp, de előtte.. na .. feltételezem, tisztában vagy a szoftverfejlesztés főbb állomásaival és az egyes állomások erőforrás igényével, szerintem nem kéne csodálkoznod, hogy tesztelésről van szó, igen, fejlesztői teszt DEV-en, egy ilyen laptopon, lazán. Előző munkahelyemen egy pénzügyi startup-nál giga portál tesztelődött ugyanígy lokál laptopon 8G RAM-al és ment fel utána a nagyvasakra következő fázisba, végül állt élesbe felhőben és csattantak rá többszázezren. Nincs ebben semmi különös, pedig ott azért nem a snake-et írogatták.
No offense, csak ne dobálózz már olyanokkal, hogy én dobálózok, egyrészt nem dobálózás, másrészt direkt hozok ilyen példát, mert mindenki - lásd, még egy szakmabéli is - azt gondolja, ezek ilyen ördögtől való boszorkánykonyha "atyaúristen" elérhetetlen szupertechnológiák, amiket ne lehetne ledemózni 3 csoffadt kis VM-en. Dehogynem lehet, röhögve, nekünk powerpoint helyett élesben ment az főnökök előtt, hogy kirúgtuk az egyik lábát és néztük, mikor hogyan viselkedik melyik node, később ugyanez durvább teljesítmény teszt alatt, meg még több tucat egyéb..
Most mi is 150+ magos dedikált farmon futtatjuk a motyót elképesztő mennyiségű RAM-al, de ez már más tészta. És 3 fentebb említett szaros kis VM juttatott minket oda, hogy elkezdjük ezeket tisztességesen kitesztelni, megnyúzni, agyonhajtani, használni, meg az én hajnalba nyúló óráim itthon az akkor még csöpp konfigomon, nem a consulting cég jött csillióért megmondani nekünk a tutit. Ja bocs, de, de ők azt se tudták, mi ez még tavaly és hoztak egy olyan megoldást elsőre, ami ugyan HA-t adott, de konzisztenciát nem, meg még pár egyéb dolgot sem.
Ne dobálózzunk olyanokkal, hogy mit lehet és mit nem, mert csak kreativitás és odafigyelés kérdése és nagyon sokmindent lehet.
-
Frawly
veterán
válasz
Dißnäëß
#30103
üzenetére
Ja, hobbivirtualizációra, OS-eket tesztelni, meg minimális OS-eket építeni jó az 512 MB RAM egy prociszállal. De ezzel komoly dolgot nem tudsz kezdeni, én VM-nek is minimum 4 GB RAM-ot és min. 2 prociszálat adnék, az is abszolút minimum. Ilyen 1 vCPU meg 512 MB RAM-nál abszolút felejtősek azok a dolgok, amivel dobálózni szoktál, ZFS RAID, meg MySQL InnoDB és társai.
-
Dißnäëß
nagyúr
válasz
Frawly
#30102
üzenetére
Hát feszegettem szerver célra, a környezet laptop volt mindvégig. Nem írta meg a kérdező, milyen CPU végül. Vt-d nélkül sok esély nincs, vt-d-vel is csak szolídban, kicsiben (i5 és fentebb az ő esetében, új vasaknál már az i3 is 4-magos + vt-d-s).
Na közben meg is van a Deb10 testing friss install egy 1 magos 512 RAM-os VM-be.
root@debian:~# free -h
total used free shared buff/cache available
Mem: 482Mi 56Mi 350Mi 0.0Ki 75Mi 413Mi
Swap: 509Mi 0B 509MiLehet ezzel bohóckodni sokat
Kérdés, mit akar virtualizálni. 8G fizikai RAM-al még egy 4G-s W10-et is tud, igaz, mire bejön, elmehet vacsizni közben Mindig a "mire" a kérdés.
-
Dißnäëß
nagyúr
válasz
Frawly
#30098
üzenetére
Öööö, szerintem ne nekem
De nagyjából kifejtetted kicsit részletesebben, amire én is utaltam a kérdezőnek.@bambano: +1, igazából attól függ, mire kell. Ilyen alap logikai izolációkra, hogy semmi durva teljesítményelvárás, csak ül 1-2 buta szerver démon a maga kis elzárt homokozójában, néha kiszolgálva 1-2 kérést, még 2 fizikai mag is bőőőven oké. De újabb i3-ak 4 fizikaival pláne, igen.
De Frawly-nak is igaza van, csak lehet, félreértett engem (vagy én fogalmaztam nemjól), eszem ágában nem volt i3-azni szerverbe, de kérdés, mit tekintünk szervernek. A home lab, vagy egy fejlesztő kezében egy sima laptop is lehet "szerver" arra a pár órára, míg beröffenti a dolgokat, mert miért ne lehetne. (Legalábbis nálam ez tipikusan ilyen kis szerver / nagy szerver kategória, ma már bármi lehet szerver, egy Raspberry Pi is.. meg ugye környezet függő, DEV-nek jó lehet, PROD-nak nyilváááán SOHA)
Még mindig a fejlesztéshez vissza, mert pont ebben vagyok én is mostanság: HAProxy-s pacemaker-es loadbalancer-es felállást meg minden ilyen "ökörséget" kicsiben tökéletesen el lehet játszani Virtualboxokban is egy Windows host-on, én így csináltam pár éve, igaz gamer laptop volt 4 maggal, de 1 szálat kapott minden és miután beboot-oltak a VM-ek, idle-ben ott üldögéltek kb. az idő 99%-ában, viszont konfigolgatni, demózni, próbálgatni ezt-azt nagyon hasznos volt a kis mini-lab. A 8G RAM elég sokmindenre, egy Debian "standard" installer iso pedig desktop nélkül 1 vCPU-val és 512 RAM-al elég jól tud hasítani, valami 80 MB az alap RAM igénye az első friss telepítés után, de mindjárt lepróbálom egy netinst-en.
Az előbb próbálgattam pár beállítást.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
Új hozzászólás Aktív témák
Hirdetés
- Autós kamerák
- Szeged és környéke adok-veszek-beszélgetek
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Kerékpárosok, bringások ide!
- Filmgyűjtés
- Honor 400 - és mégis mozog a kép
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Telekom mobilszolgáltatások
- Projektor topic
- TCL LCD és LED TV-k
- További aktív témák...
- Eladó Steam kulcsok kedvező áron!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- Bomba ár! Lenovo ThinkPad L380 - i5-8GEN I 8GB I 256SSD I 13,3" FHD / MT I HDMI I Cam I W11 I Gari!
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
- Bomba ár! Lenovo X1 Carbon G6: i7-8G I 16GB I 256-512 SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- iKing.Hu - Honor Magic 7 Pro - Black - Használt, karcmentes
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged