- Canon MILC: EOS R és M topik
- AMD Navi Radeon™ RX 9xxx sorozat
- CPU léghűtés kibeszélő
- Autóhifi
- SSD kibeszélő
- Hálózati kábelek és szerelésük
- Kormányok / autós szimulátorok topikja
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Amazon Kindle
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
-
PROHARDVER!
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
-
bucihost
senior tag
válasz
bambano
#25435
üzenetére
A tiltás is folyamatban van, csak sajna olyan helyekről is érkezik támadás (Románia, Szlovákia, Szerbia, Német, Osztrák, stb) ahonnan sok magyar hallgató érkezik. Persze szingapúr és társai tiltásra kerülnek..
Bár most épp magyar IP-k tömkelege támad (a 3-as limitálás már sokat redukált rajta). De még így is dühítő.
-
Rimuru
veterán
-
#25442
King Unique
titán
sonar
#25429
King Unique
titán
Azért mert csak "full root módban" csinálja meg, a sima sudo nem feltétlen elég neki. Az "ubuntu.iso" helyére meg nyilván a pontos elérési utat kell beírni, de ezt gondolom vágod. Ez az alak meg csak annyival tud többet, hogy menet közben mutatja a folyamat állását. Egyébként mindkét módszer DD módban írja ki az ISO-t, szóval ilyen téren kb. ugyan mindegy melyiket használjuk. Valamint nyilván UEFI boot módban is működik mindkettő, legalábbis nálam igen.
Amúgy meg nem muszáj ilyenekkel szenvedni, nemrég említettem egy jó grafikus programot.
-
bucihost
senior tag
Mivel jelen esetben egy adott port volt támadva, és 1 ip többször is szerepelt, így iptables-ben létrehoztam egy szabályt, hogy az adott porton lévő szolgáltatást 1 IP-ről csak 3 szor lehessen "megnyitni". Majd kiderül, elértem e vele valamit vagy sem. A szerver előtt egyébként van ddos védelem, amit a szerverterem ad. Az véd is, csak amikor az adott portot árasszák el kapcsolódással arra nem véd már..
-
bambano
titán
az általam írt mondat helyes értelmezése az, hogy a kernel a védő eszközök között szerepel, mint az applikáció előtt levő dolog, nem pedig a védelemre szorulók között, amennyiben ez a fajta ddos elleni védekezés a téma, amiről itt szó van.
"A kernelt nem kell védeni úgy általában, ez csak a sysadminok fejében elő marhaság": tartok tőle, hogy ezt se a linux kernel fejlesztők, se a microsoftos kernel fejlesztők nem így gondolják.
-
Frawly
veterán
válasz
bambano
#25427
üzenetére
Így van. DDoS ellen a drót másik végén kell védekezni. A helyi gépen esélytelen, mert mire eldobunk egy csomagot helyi tűzfallal vagy kernellel vagy akármivel, addigra már a sávszél felemésztődött, a csomag bejött, feldolgozásra került, legfeljebb el lett dobva, de a sávszélességet, erőforrásokat addig is foglalta.
-
-
bambano
titán
pontosítsunk egy kicsit.
a ddos elleni védekezés alapja, hogy amit védeni akarsz, az előtt kell védekezned. mivel a kernel és a linux tűzfal ebből a szempontból a gépen futó szerver programok előtt van, így azokat elvileg lehet védeni. a bejövő internet kapcsolatot nem tudod védeni, mivel a védekezésnek a drótod túloldalán kellene kezdődnie. -
-
bucihost
senior tag
Sziasztok!
Tudnátok valami program csomagot ajánlani linuxra (ubunti szerver) ami DDOS ellen védene? AZ egyik stream szervert az imént letámadták, generáltak rá 1600 "hallgatót". Többnyire proxy volt, és 1 IP többször is csatlakozott. Meglehet azt valahogy oldani, hogy proxyval egyáltalán ne legyen elérhető a szerver, valamint hogy 1 IP-ről 1 időben csak X élő kapcsolat lehessen?
-
bambano
titán
a cikkben van ez a példa:
head -c 100MB >akarmi.isocsinálj már egy 256TB-s iso-t dd nélkül please. vagy ha mindenre jó a cat meg a cp, amire a dd, akkor másolj már le egy hibás adathordozót cat-tel...
a pv meg nem része az alap debian telepítésnek.
szóva pöpetz cikk, csak kb. nincs benne egy értelmes tanács se.
-
Frawly
veterán
-
válasz
#21078528
#25417
üzenetére
Ezek szerint lehet ez a fura router jelenség is az ok!? Van benne logika, mert nem mindig jön elő, viszont két más net eléréssel rendelkező ugyanazon disztrón is jelentkezett. Csak be kell akkor üzemelnem az Asus RT N12-t, pedig azt vevő-nek szántam másik helyiségbe.
Köszi a tippet, valahogy erre nem gondoltam túl erősen eddig!
Reggel pingeltem az ntp-t, de minden OK volt vele, csak közben egy laptoppal szenvedek meg testdisk-kel próbálom visszanyerni az elveszett partíciót, amit áthelyezés közben kinyírtam az Alt+F2-vel gparted futás alatt.
Ma egész ügyesen szivatom magam.
-
-
válasz
#21078528
#25414
üzenetére
Je értelek! Köszi, így már tiszta. Reggel letesztelem ezeket, arra is gondolok, hogy jó ideje vacakol a routerem, az is okozhatja ezt a jelenséget, na meglátjuk! (ezt jól el is felejtettem)
Holnap referálok a dologról, addig is köszi nektek! -
válasz
#21078528
#25410
üzenetére
ubyegon@ubymint18 ~ $ sudo ntpq -p
[sudo] ubyegon jelszava:
ntpq: read: Connection refusedPING index.hu (217.20.130.99) 56(84) bytes of data.
64 bytes from index.hu (217.20.130.99): icmp_seq=1 ttl=57 time=2.15 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=2 ttl=57 time=2.44 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=3 ttl=57 time=1.41 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=4 ttl=57 time=1.30 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=5 ttl=57 time=5.70 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=6 ttl=57 time=2.26 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=7 ttl=57 time=2.75 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=8 ttl=57 time=2.39 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=9 ttl=57 time=2.38 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=10 ttl=57 time=2.05 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=11 ttl=57 time=2.32 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=12 ttl=57 time=2.31 ms
64 bytes from index.hu (217.20.130.99): icmp_seq=13 ttl=57 time=2.17 msMost akkor kell az az ntp.service? Hogy kapcsoljam vissza?Jó, rájöttem,disablehelyettenable...bocsi, ezt még nekem is tudnom kéne.
Szóval nem kell desktopon ez nekem.
Bocs Vladi főnök! Jól összeszemeteltem a guru topikot!
-
Vladi
nagyúr
válasz
#21078528
#25410
üzenetére
az ntp ugyebár elengedhetetlen egy otthoni desktopon.
Lassan meg kell barátkozni olyan dolgokkal, hogy systemdé, meg grub2, meg hasonlóak.
Eskük nagyon hiányoznak a régiszéplinuxos idők, mikor triviálisan lehetett átlátni a rendszert.
Március 31én azért csak szomorkodm majd egy kicsit.
-
Attól, hogy bent vagy a desktopon még a háttérben szüttyöghet egy kicsit.
OK, de ezelőtt hárommal várakozott a desktopra 1,5 percet, most meg bejött hamar, kb. mint eddig!
Jessie már csak nevében az régóta, strech/experimental frissítéseket szokott kapni, bár már egy hónapja nem néztem.
systemdével nincs nekem bajom, eddig azt se tudtam, hogy van, ill. tudtam csak nem érdekelt!
![;]](//cdn.rios.hu/dl/s/v1.gif)
-----------------------------------------------
Most visszajöttem és piszok gyorsan bootol a Mint, viszont ezt kiírja még (Bootup is not yet finished)
1 perc múlva is, viszont ha bebootol rendesen, akkor nem érdekel.ubyegon@ubymint18 ~ $ systemd-analyze blame
1.127s postfix.service
1.083s nmbd.service
1.063s samba-ad-dc.service
653ms lvm2-monitor.service
549ms networking.service
518ms ModemManager.service
465ms accounts-daemon.serviceÚgy látszik, kilőtte a lassító folyamatokat...ez már nem tűnik vészesnek.
Köszi nektek, alakul ez!
-
#21078528
törölt tag
"Ez az egyszerre systemd meg sysvinit egy nagy kupleráj."
Egyetértek!
Systemd-s rendszeren a systemd-timesyncd-t kéne használni, nem az ntpd-t...
(#25403) ubyegon2: az ntp beállításait kéne megnézni, valszeg nem éri el a beállított szervereket (nézd meg, hogy pingre mit válaszolnak).
A sudo ntpq -p egyébként mit mond?
-
#25409
King Unique
titán
Lenry
#25392
King Unique
titán
Én mondjuk így szoktam, de a vége elhagyható. Egyébként sok Linux ISO eleve hibrid és mindkét féle módon kiírhatók. A kolléga által említett UNetbootin egyébként az első opció szerint csinálja. A DD íráshoz pedig jó grafikus megoldás (lehet) például a multiplatformos Etcher. Nemrég cikkeztek is róla. Igaz, még béta állapotú, de már több rendszeren is használtam és ok volt.
-
Vladi
nagyúr
válasz
ubyegon2
#25407
üzenetére
Várjál kicsit. Attól, hogy bent vagy a desktopon még a háttérben szüttyöghet egy kicsit.
Utána nézd meg a kimenetet.ipv6-ot nem.
Jessiet felteheted, de egy x idő múlva az is elavul és akkor frissítened kell.
Meg kell barátkozni a systemdével. A centos 6-nak is már csak 3 éve van...
-
Kiszedtem, leszedtem a netex73-at is, ugyanaz a helyzet,
Bootup is not yet finished. Please try again later., azonban gyorsabban bebootolt és belőtte a FF-ot is. Fene se érti ezt, igazából ha bebootol gyorsan, akkor a fenét se érdekli a systemd-analizé.Ez a sysvinit/systemd keveredés nekem is feltünt a kimenetben előbb.
Pár lépésre vagyok attól, hogy újra a Jessie-t használjam állandóra.
Az Ipv6-ot nem kéne kikapcsolni?
***************************************************************
Már Jessie sem a régi, egészen lelassult a boot.
ubyegon@debian:~$ systemd-analyze
Startup finished in 2.084s (kernel) + 9.329s (userspace) = 11.413sMost már elegem van az Ubuntu alapúakból egy időre! Maradok a jó öreg Jessie-n.
Köszi nektek, hogy próbáltatok segíteni, ha valami megoldás beugrik, azért szóljatok, de most Jessien kívül csak valami anno Arch alapú jöhet számításba.
-
Mostanában nem, de ez a netex nem is kell ide, csak a schedulereket raktam bele anno.
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
echo noop >/sys/block/sda/queue/scheduler
echo deadline >/sys/block/sdb/queue/scheduler
echo deadline >/sys/block/sdc/queue/scheduler
bash /opt/NeteXt73/APM/apm_status_fix
bash /etc/apm-ext73/wol false
bash /etc/apm-ext73/advanced_power_management_by_ext73_performance-ondemand_v5.2 false
exit 0remélem ezzel kilőttem a háló időt
ubymint18 ubyegon # systemctl disable ntp.service
Synchronizing state of ntp.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install disable ntp
insserv: warning: current start runlevel(s) (empty) of script `ntp' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `ntp' overrides LSB defaults (1).
de ha a szokásos 100-150 hallgató hirtelen felugrik 1700 ra mint ma reggel is, az már tuti támadás 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eladó Steam kulcsok kedvező áron!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! LENOVO Ideapad Gaming 3 notebook - i5 11320H 16GB DDR4 256GB+1TB SSD GTX 1650 4GB WIN11
- Samsung Galaxy S21 Ultra , 12GB , 128 GB , Kártyafüggetlen
- BESZÁMÍTÁS! Gigabyte G5 KC Gamer notebook - i5 10500H 16GB DDR4 512GB SSD RTX 3060 6GB WIN10
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32 RAM RTX 5060Ti 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest