- Hivatalos a OnePlus 13 startdátuma
- Poco F3 - a mindenes, de nem mindenkinek
- Android alkalmazások - szoftver kibeszélő topik
- Apple iPhone 16 Pro - rutinvizsga
- Google Pixel topik
- Mindenki Z Fold7-et akar
- Fotók, videók mobillal
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Három Redmi 15 érkezett a lengyel piacra
- Telekom mobilszolgáltatások
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Ubuntu Linux Összefoglaló
Hivatalos Ubuntu dokumentáció
Amennyiben kérdésed lenne, kérünk, add meg a szükséges adatokat a hiba minél pontosabb leírása mellett:
-számítógép típusa, hardverek pontos megnevezése (különösképp videókártya, vagy hálózati egységek)
-a használt rendszer pontos neve, verziója, a grafikus felület
-mikor és hogyan jelentkezett hiba, mi váltotta ki (program telepítés, frissítés, ...)
-eddigi próbálkozások a megoldásra (ha voltak ilyenek)
A hardverinformációkat legegyszerűbben úgy gyűjtheted össze, ha megnyitod a Terminál nevű programot a menüben. Ide írd be a következő parancsokat (mindkettő után nyomj Enter-t):
lspci
lsusb
Új hozzászólás Aktív témák
-
válasz
Formaster
#41162
üzenetére
Igen, akkor semmihez.
Mondjuk ha fizikailag oda lehet menni a géphez, akkor mindegy is. Amihez valaki fizikailag hozzáfér, az törhető.
Ha nem lehet, akkor meg nem kell jelszavazni a GRUB-ot sem, konzolos hozzáférést engedhetsz, távolról nem tud betörni, fizikailag sem. -
válasz
Formaster
#41160
üzenetére
A Grub alóli jelszóhackelés nem egy feature, nem tudod kikapcsolni.
Jelszavas Grub a barátod.Nyilván ez olyan hogy user szinten tiltasz mindent, rootot, usereket, és ha mégis be kell menni, akkor az init=/bin/bash hack-kel tudsz jelszót adni, és be lehet jelentkezni konzolról vagy SSH-val.
Illetve. Hol van ez a gép?
Mert ha felhőben, és létezik konzolos hozzáférés, amihez neked van jelszavad, akkor elég a sshd-t leállítani, és akkor csak konzolról lehet bemenni.
-
válasz
Formaster
#41156
üzenetére
Na ehhez kéne tudni, hogy mit értesz hozzáférés alatt, és hogy nem szabad hozzáférni?
BTW ha kihúzod 220-ból, akkor nem lehet hozzáférni, amíg valaki be nem dugja
@I02S3F : Ja, VM futtatáshoz nem árt RAM. Most teszteltem amúgy, a Wayland elég nagy zabáló. 4GB-os x86 tablet, Wayland bekapja a 4GB-t, ha KDE, ha Gnome, ha Phosh fut. Visszaváltok X-re, máris 1,7GB Gnome-al. (Debian, de a KDE Neon is evett 4-et Wayland-el.) (Viszont X-en a touch kezelhetőség rosszabb.)
-
stopperos
senior tag
-
-
stopperos
senior tag
válasz
Formaster
#40909
üzenetére
XFS és EXT4 között nem sok különbség van. Én az elsőt szoktam választani (egy lemez, mdadm raid, ...). Nem kell semmit konfigurálni, mert az alap beállítás szerint a leggyorsabb verziót kapod (ha raid, akkor detektálja a legkisebb foglalható méretet).
Az ECC témáról pedig csak annyit, hogy túl van pörögve. Természetesen minden esetben jól jön, de otthoni környezetbe én nem tapasztaltam hiányát.
Én 17 éve foglalkozom rendszergazdasággal. Több helyen (cég, kollégium, egyetem) üzemeltetek adattároló szervert. Akár összekukázott hardverből akár szerver hardverből, amire keret van. Itthonra például egy Amd C60 processzoros alaplapon van az egész 4 GB memóriával. Szerintem a ZFS témáról olvasd el itteni írásomat. Az utóbbi 8 évben csak zfs alapú rendszereket húztam fel, és bár merevlemezt vesztettem, adatot nem, mert volt elég redundancia.
-
inf3rno
nagyúr
válasz
Formaster
#40907
üzenetére
Bármi lehet. ZFS-nél block checksum van, ott egy blokk szokott sérülni, és az azon lévő fájlok. Ha töredezett a lemez, akkor ez sok fájlt érinthet, és nehéz megmondani, hogy azon belül pontosan melyik fájl sérült, ott meg kell nézni az érintett fájlokat egyesével. SSD-nél nem tudom, valószínűleg ott is. Előfordulhat ugyanez, ha kisebb hibák vannak. Ha nagyobb a hiba, akkor kuka az egész, és a teljes lemezt vissza kell állítani.
-
inf3rno
nagyúr
válasz
Formaster
#40905
üzenetére
Szerintem csináld a mostani géppel ZFS-el, és csinálj backupot róla. Az adatvesztés ellen a biztonsági mentés véd, a RAID inkább arra jó, hogy ne kelljen leállni, ha tönkremegy egy lemez, illetve gyorsítja az írást, olvasást, ha olyan típusú.
A ZFS-nél érdemes nem a teljes lemezre, hanem partícióra csinálni a RAID-et, és egy picit lecsípni a partíció méretből. Azért jobb így, mert a ZFS-nél nincs olyan, mint a BTRFS-nél, hogy eltérő méretű lemezekből rakod össze a tömböt, csak azonos méretűek lehetnek, aztán ha egy kiesik, és később pótolni kell, akkor elképzelhető, hogy másik gyártótól nem lesz bitre pontosan ugyanaz a lemezméret, később meg már macerás átméretezni. Ha esetleg tartasz attól, hogy fizikailag ellopják a lemezt, vagy valaki hozzáfér az adatokhoz ott helyben, akkor a ZFS támogat fájlrendszer szintű titkosítást. Amennyire én tudom a többi fájlrendszernél külön LUKS kell, és az jóval macerásabb, hogy van egy RAID-ed, és még arra külön teszel titkosítást.
-
inf3rno
nagyúr
válasz
Formaster
#40900
üzenetére
Nem muszáj, enélkül is ritka az adatvesztés. Ha nem vállalkozás adatai vagy ilyesmi, hanem pl. családi fotók, akkor egy sima backup készítés is elég lehet. 1-2 fotó elvesztése nem szokott világvégét jelenteni.
Az ECC-re váltás nem annyira egyszerű manapság, mert százezer felett vannak az ECC-s Intel lapok, az AMD ECC támogatása meg consumer grade lapokon nem tudni mennyire létező vagy megbízható. Nekem van egy régi s1151-es ECC-s lapom, azt el fogom adni az aprón, mert én is túlzásnak érzem, bár leginkább azért, mert nem megy bele egyszerre egy M2-s kártya és egy 56Gbps optikai hálózati kártya, így meg értelmét vesztette a mostani belső hálómban. Én inkább áttérek arra, hogy EXT4, dupla backup, és fájlonként csinálok mindenre checksumot. Aztán ha sérült valamelyik fájl, és hibás a checksum, akkor nyomozok, hogy vajon a backup vagy a szerveren lévő fájl e a hibás. Nekem itthonra nem kritikus, hogy 24/7 fussanak a szolgáltatások, illetve eleve úgy írok mindent, hogy támogassák ezt a fajta megközelítést pl. event storage-ből kimentve minden event külön checksumos fájlba kerül. Ha űzlethez kell és fontos, hogy állandóan menjen a szerver, akkor ECC és ZFS szerintem a legjobb megoldás. A BTRFS esetleg annyiból rugalmasabb, hogy eltérő méretű lemezekkel is működik, de a ZFS-t egy fokkal megbízhatóbbnak érzem.
-
inf3rno
nagyúr
válasz
Formaster
#40896
üzenetére
A ZFS és BTRFS azért jobbak egy sima EXT4-nél, mert block checksum van rajtuk, amit ellenőriznek olvasásnál, és ha RAID-be teszed őket, akkor automatikusan javítják a sérült adatot, ha van redundancia. Volt régebben ilyen városi legenda, hogy a hibás memória miatt ez az ellenőrző mechanizmus felülírhatja a jó adatot is hibással, mert a checksumja nem jön ki. [link] Úgy tűnik nem volt igaz. Viszont az ECC így is erősen ajánlott, ha fontos az adatod integritása. A többi RAID megoldásnál úgy tudom nincs ilyen checksum, és ott vagy vége a világnak, ha az egyik példány sérült az adatból és felhasználói beavatkozás kell, vagy simán felülírhatja a hibással a jót. Legalábbis olvastam erről is régebben. Van még azt hiszem olyan funkció ezekben, hogy tömöríteni lehet az adatot, aztán ott még jobban be tud kavarni a hibás memória. De már olyan 5 éve olvastam ezekről, amikor összeraktam itthonra a szerverem. Azóta sem használtam. Kiderült, hogy nincs időm erre, meg egyelőre megúsztam a hibás SSD-ket. El is adom a cuccot nem sokára, aztán maradok egy sima EXT4-nél meg sűrű backupnál.
-
válasz
Formaster
#40884
üzenetére
Engem is érdekelne. A virtuálhostomban tükrözve van két lemez, és az írás elég ergya.
(@Inferno, nincs benne ECC RAM, maradhat ? )
Ezeket találtam, de csak a resync-re hat elvileg. -
sonar
addikt
válasz
Formaster
#40887
üzenetére
Nem tudom, szerintem nem egészen korrekt az oldal. Write speed-re azt írja, hogy nincs változás.
Ez vmi elméleti matekolós oldal.
Mostanában már nem szerverezek, de ha a raid5 data-nak volt használva (tehát az OS nem arról futott) akkor sem értük el a 2x sebesség növekedést. Viszont írásban is volt rendesen sebesség növekedés.És ahogy előttem is írták a cache amivel lehetett durván növelni a sebességet. (raid kártyán a Read Ahead feature-rel tudtam még látványos növekedést elérni, de csak olvasásban és nagy file-oknál)
-
inf3rno
nagyúr
válasz
Formaster
#40883
üzenetére
Nekem eddig, ami sebességben a legtöbbet számította az a buffer méret, olyan tizedére húzta le a sebességet a túl alacsony buffer méret. Igaz az nem RAID volt. ECC memória nélkül nem nagyon állnék neki szoftveres RAID-nek, ha meg nekiállnék, akkor BTRFS vagy ZFS lenne.
-
Formaster
addikt
-
-
#40612
lionhearted
őstag
Formaster
#40611
-
lev258
veterán
válasz
Formaster
#38728
üzenetére
Mint írtam, az fura.
Terminálba ezt bemásolva látnod kell minden érzékelt usb eszközt:for sysdevpath in $(find /sys/bus/usb/devices/usb*/ -name dev); do ( syspath="${sysdevpath%/dev}" devname="$(udevadm info -q name -p $syspath)" [[ "$devname" == "bus/"* ]] && exit eval "$(udevadm info -q property --export -p $syspath)" [[ -z "$ID_SERIAL" ]] && exit echo "/dev/$devname - $ID_SERIAL" ) done -
#38703
lionhearted
őstag
Formaster
#38687
válasz
Formaster
#38687
üzenetére
Aha. Hát a use-caset nem igazán értem, mert ha ez egy publikus oldal, akkor pont a login.php a tűzválasztó authorizált és nem authorizált kérésekben...
Így viszont csak olyan helyen megoldható, ami tudja szűrni a HTTP kéréseket, ami üzleti szintű tűzfalak vagy a webszerver/proxy (itt nginx?).
Utóbbiban:location /login {
allow 192.168.1.1/24
deny all;
} -
#38686
lionhearted
őstag
Formaster
#38685
válasz
Formaster
#38685
üzenetére
Szia!
Mivel úgy írod, hogy belső hálózat meg külső, így feltételezhető hogy a határán van tűzfal. Ha ott nincs nyitva, akkor nem elérhető már most se.
Egyébként az adott gépen lévő tűzfalon se árt korlátozni, ez Ubuntus gépeken azufwnevű csodával van segítve. Pl:ufw allow from 192.168.1.0/24 to any port 8080/tcp -
samujózsi
senior tag
válasz
Formaster
#36706
üzenetére
Ismerős
És persze ahány tutorial, annyi variáció.
Első körben azt mondanám, hogy hagyd így, csak a raidmd127 kapjon fájlrendszert ÉS mount pointot próbaképp. Van valami halvány emlékem, hogy bugos a telepítő és a benne létrehozott eszközökkel van némi gondja, ha nem lesz mountolva a telepítés végén minden.
Persze a tévedés jogát fenntartom. -
-
-
lev258
veterán
-
-
Frawly
veterán
válasz
Formaster
#35578
üzenetére
Ja, így már értem, hogy Ubuntu Server. Próbáld meg kiadni a dhcpcd interface_neve parancsot. Azt nem írtad, hogy milyen kapcsolatról van szó, gondolom szervernél Eth lesz, de meg kéne nézni mi a neve, látszik-e egyáltalán az eszközök között.
Ha nem konfigoltál bele speciális beállítást, akkor dhcpcd-vel kéne IP-t kapnia.
35580) sonar: lehet neked lesz igazad, és Ubuntu alatt nem dhcpcd-nek hívják, hanem dhclientnek vagy valami másnak. Egy „ip a” kimenetet is megnéznék.
-
válasz
Formaster
#35578
üzenetére
Az elég durva, ha serverhez nem rakták fel, mert amúgy elég nyűgös beállítani, ahogy nézem, próbált meg az itt leírtakat.
Network Configuration server 18.04
https://pkgs.org/download/network-manager
Vagy innen próbáld máshogy, máshol, valahogy leszedni akár pendrive-ra a .deb csomagot.
-
Frawly
veterán
válasz
Formaster
#35574
üzenetére
Nem értem, 18.04 LTS-en alapból ott kéne lennie a Network Managernek előtelepítve, nem kell külön leszedni. Az a Gnome, ami benne van, magával hozza függőségnek. A Network Managert grafikus felületről is eléred, a tálca jobb sarka felé szokott lenni, ahol le tudod nyitni a hálózati kapcsolatokat.
De csinálhatod terminálból is, úgy biztosabb. Ahhoz, hogy pontos parancsokat írjak, kéne tudni, hogy milyen kapcsolatot akarsz életre kelteni, Wi-FI, vagy vezetékes.
-
Frawly
veterán
válasz
Formaster
#35571
üzenetére
Network Managerben átszerkeszted a kapcsolatot, hogy automatikusan DHCP-vel kérje a címet azon a hálózati interface-en, IPv4-en és IPv6-on is külön lehet állítani. A Network Managert az adott grafikus felület tálcaalkalmazásából is eléred, de ha nem találnád, akkor terminálból indítsd az nmtui alkalmazást.
-
Frawly
veterán
válasz
Formaster
#35268
üzenetére
Egy mag teljes terhelését veszi alapból 100%-nak, ha több magos és/vagy több szálas procid van, és több mag/szál is le van terhelve, akkor több száz % terhelést mutat. Unix, Linux, unixlike rendszerek alatt mindig is ez volt a hagyományos kijelzési metódus, a load is így jeleníti meg az értékeket.
Ezt én is mindig kikapcsolom, hogy olyan legyen, mint Windowsban, hogy az összes mag+szál terhelését vegye 100%-nak és ehhez képest arányosan jelezze ki a CPU terhelést.
A top elég fapados, érdemesebb helyette feltenni a htop-ot. Azt rendes karakteres menüben be lehet állítani, és meg is jegyzi a beállításokat. Sajnos még ez sem hibátlan, mert a CPU% oszlopban nem lehet átállítani az összterhelés mutatását, ott mindenképp úgy mutatja, hogy 100% terhelés az egy mag/szál teljes terhelése, de hozzá lehet adni felül egy CPU Average sort, ami már rendesen jelzi ki, Windows alatt megszokott módon.
-
válasz
Formaster
#35268
üzenetére
Ha fut a top nyomsz 1-est és szétbontja a magokat. Elég sok opciója van a top sysmon-nak. Itt érdemes megnézni:
30 Top Command for Monitoring in Linux
példa:
Rakd ezeket egymás mellé külön terminak ablakba:top -o %MEMtop -o %CPUAz s lenyomásával változtathatod a frissítés idejét. 0.1-nél már elég gyorsan váltakoznak az értékek.
-
-
Frawly
veterán
válasz
Formaster
#35156
üzenetére
Látom már ajánlottak neked, de ha nem jönne be az, erről az oldalról tudsz alternatívák után nézni. Esetleg erre a listára is ránézhetsz.
Amúgy mire kell ez neked? Nekem utoljára a DOS korszakban kellett ilyen. Windows alatt már, ha pl. játékokba akartam belenyúlni, arra már a Cheat Engine-t használtam, ez egyfajta debugger, amiben profilokat is el lehet menteni, meg patchelni vele a binárist.
-
lev258
veterán
válasz
Formaster
#35118
üzenetére
Ha üres, valószínűleg rossz útvonalat adtál meg. És nyitott egy fájlt az általad megadott helyen.
Egyébként kíváncsiságból kérdem. Miért szerver verzió, amikor az eddigiek alapján még ismerkedned kellene a dolgok működésével? És ez utóbbiban nagy segítség tud lenni az asztali verzió. -
lev258
veterán
válasz
Formaster
#35114
üzenetére
Na most normál esetben friss telepítésnél az alsó rész nem szokott ott lenni. Nem tudom, neked is hogy került oda.
Én a helyedben törölném az egészet primary network interface-től lefelé. Még azon gondolkodok, lehet-e köze ahhoz, hogy szerveren nincs network-manager. És esetleg ezért kerülne be. De akkor sem eth0 már egy jó ideje.
ifconfig mit mond pontosan?
(@Inferno, nincs benne ECC RAM, maradhat ? 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
és ami nem működik, az volt az 
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás az Ubuntut és variánsait használók és az ezekkel még csak ismerkedők számára
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Bemutató Linux a mindennapokban
- Bemutató Ubuntu 16.04 LTS kezdőknek, gyakorlatiasan, objektíven
- Hír Megjelent az Ubuntu 16.04 LTS
- Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- LicencAruhaz.hu OLCSÓ, LEGÁLIS SZOFTVEREK AZONNAL - Windows - Office - Win Server - ÖRÖK GARANCIÁVAL
- Vírusirtó, Antivirus, VPN kulcsok
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- BESZÁMÍTÁS! Apple Macbook Pro 16" 2019 i9 64GB 1TB 5500M 8GB garanciával hibátlan működéssel
- Ritkaság! Hibátlan Prémium felsőkategóriás LGA 1700 Alaplap! Asus Rog Strix Maximus Hero Z790 Wi-Fi
- Olcsó Gamer PC-Számítógép! Csere-Beszámítás! Xeon 5650X / GTX 1650 / 24GB DDR3 / 250SSD+500HDD
- Azonnali készpénzes Apple Macbook Air felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: FOTC
Város: Budapest