-
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
-
-
-
-
heti átlag kétszer frissítek, 3 éve csak ez van a gépen, tényleg nem nagyon volt vele gond, de nyilván nem ez a szerver, nem fut rajta semmi mission-critical, a saját cuccaim mennek rajta, ami a munkámhoz éppen kell.
de egyébként 2009 óta használok Arch-ot, szóval lehet, hogy ez is közrejátszik abban, hogy kevés nyűgöm van vele
-
-
nekem a csomagkezelése fáj nagyon, hogy külön frissítsd a package-eket, meg külön az OS-t, meg külön a frissebb package-eket, portokat, aztán ha valamit nem a neki tetsző sorrendben csinálsz, akkor nem bootol.
attól is a falramászok, hogy random helyeken van minden.
hogy van a /etc, meg a /usr/local/etc, meg a /bin és a /usr/local/bin és az /usr/bin és faszér nem lehet egy helyre rakni a cuccokat, hogy ne kelljen mindent 22 helyről összevadászni, ha valamit át szeretnél állítani...a kolléga, aki nem az OS-t b*szogatja mint én, hanem a rajta lévő cuccokat, azt mondja, hogy csomó olyan dologba fut bele, hogy jó-jó hogy itt is van mondjuk apache, csak nem ugyanolyan, meg nem lehet rajta megoldani, amit Linuxon igen, stb.
anno elsősorban a ZFS miatt használtuk, mert az tényleg nagyon jó, de mára Linuxon is van rendes ZFS támogatás, így okafogyottá vált a vele való szerencsétlenkedés
-
-
válasz
Vastika #30951 üzenetére
nálam így néz ki a szkennelő scriptem releváns része
scanimage --device net:192.168.1.2:hpaio:/usb/Deskjet_2510_series?serial=CN2BQ3JPKF05TX --mode Color --resolution 300 --progress --format=TIFF > ~/scan_$CURRENTDATE.tiff
ez nálad is megvan mind? mert valami paramétert hiányolmásrészt tuti van jogosultságod használni az USB eszközt más gépről?
az itt leírt megoldást nézted már? nekem anno ez segített -
válasz
bambano #30923 üzenetére
van gyártó, ami elcigánykodja és csak windowsos frissítő appot ad ki, és nem tölthető le a fw file amit be tudnál adagolni a BIOS-nak.
most kíváncsiságból letöltöttem a frissítőta kolléga laptopjához, egy önkibontós exe, amivel még megbirkózott a wine, de ahelyett hogy a firmwaret bontotta volna ki, egy másik exe van benne, ami a frissítő program lenne (gondolom)
-
-
-
válasz
Dißnäëß #30892 üzenetére
örömbódottá, de nekem erről még mindig Árpi és az Opel sztorija ugrik be
-
-
válasz
sh4d0w #30855 üzenetére
jó hogy ezt írtad, eszembe is jutott egy mai eset kapcsán.
összeraktam egy VM-et a legfrissebb Ubuntu LTS-el, rakom fel a dockert, indítanánk benne amit akartunk, az apache fogja a 80-as portot... milyen apache? nem is raktam fel apache-ot. látszólag nincs is, de a process létezik, hiába lövöm ki, restart után megint ott van.
root@host:/# ps aux | grep apache
root 1212 0.0 0.1 16528 4764 ? Ss 10:26 0:00 /usr/sbin/apache2 -k start
www-data 1213 0.0 0.1 1221408 5184 ? Sl 10:26 0:00 /usr/sbin/apache2 -k start
www-data 1214 0.0 0.1 1221408 5184 ? Sl 10:26 0:00 /usr/sbin/apache2 -k start
root 2032 0.0 0.0 5192 676 pts/0 S+ 10:29 0:00 grep --color=auto apache
root@host:/# ls /usr/sbin/apache2
ls: cannot access '/usr/sbin/apache2': No such file or directorymeg kiderült, hogy a dockert hiába a Docker saját repojából akartam felrakni, azért valahogy mégis egy snap kúszott a gépre... meg egy csomó másik.
töröltem az egész VM-et a francba, készítettem egy újat, Debiannal, ami csak azt és csak úgy csinál, ahogy azt utasításba kapja és nem akar okosabb lenni nálam.
-
-
-
-
válasz
Dißnäëß #30807 üzenetére
minden réteg annyit lát, amit az alatta lévő réteg, számára értelmezhetően megmutat.
ha az alsó réteg úgy működik, hogy "majd én megoldom a hibákat", akkor a fölötte lévő soha nem fogja megtudni hogy bármi történt, még föntebb még esélytelenebb.ha a fizikai réteg fölött lévő akármi lekezeli a hibát, átrakja az ott lévő adatblokkokat valami egészséges helyre, arról a fölötte lévő réteg nem fog tudni, miért is tudna, nem ő kezeli, nem is találkozik a fizikailag hibás szektorral, az ő általa látott eszközben már nem fog mutatkozni a hiba, hisz' azt lentebb kezelésbe vette az ottani réteg.
és ez valójában így is van jól.
ha 2-3-10 logikai réteggel föntebb is látszik egy fizikai hiba, ott nagy gebasz van. -
-
válasz
kovaax #30786 üzenetére
egyszer írtam egy systemd daemont valami scripthez, nagyon jól működik azóta is (annyira, hogy most hirtelen azt se tudom hol csinál mit), aztán egyszer kellett volna valami hasonló egy másik gépen, az eredeti alapján írtam egy újat és az istenért sem volt hajlandó működni.
ráfogtam a systemd-re, hogy biztos azért -
-
válasz
I02S3F #30773 üzenetére
annyi haszna egyébként lehet, hogy ha nem nálad fut a VM, hanem egy központi szerveren, akkor onnan tudod használni az alkalmazásokat (nagyvállalati környezetben ez sokszor előfordul), de nyilván ilyen esetben is egyszerűbb felrakni egy bármilyen RDP klienst a Linuxra.
-
válasz
sh4d0w #30770 üzenetére
Home-ban alapból egyáltalán nincs RDP, Pro-ban pedig csak egy konkurrens kapcsolat van engedélyezve, de létezik erre ingyenes program, amivel fel lehet oldani a korlátozást
-
-
válasz
Apollyon #30688 üzenetére
áh
Az általam kezelt gépek mind Iain M. Banks Kultúra-sorozatában megjelenő űrhajókról kapják a nevüket (érdemes átfutni a listát, vannak közte igen elborultak
), a Vavatch egy Halo-szerű lakható gyűrű (orbital) ugyaninnen.
-
-
-
-
-
válasz
growler #30678 üzenetére
egy héttel ezelőttig valószínűleg az Arch-ban is ez volt, ami nem világos, hogy miért állt át...
nem frissítés volt (vagy ha igen, akkor el lett kúrva), mert az Arch csomagkezelője a pacman nem ír felül konfigfájlokat, ha azt látja, hogy ahhoz kézzel hozzá lett nyúlva, hanem csak mellérakja az újat .pacnew néven, aztán majd összefésülöd őket, amikor és ahogy akarod.
és most látom, hogy szeptember közepe óta figyel egy logind.conf.pacnew a fenti mappában és abban is KillUserProcesses=no van -
válasz
sh4d0w #30675 üzenetére
mondom, hogy ott nem látszik semmi extra, de egyébként igazad volt, a systemd lövi agyon őket, szándékosan
"systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes"."/etc/systemd/logind.conf-ban kell visszaírni a
KillUserProcesses=yes
-tno
-ra -
-
mi lehet a kehe a rendszernek, hogy ha minden logout után eldob mindent? be voltak töltve az SSH kulcsok? viszlát! futott egy screen? hát, már nem fut! ésatöbbi.
a múlt héten még jó volt, de sehol semmi hibát nem látok (bár a journalctl-ban amúgyse igazodok ki rendesen)
azt se tudom merre induljakArch Linux, néhány naponta frissítve, ahogy kell
-
-
válasz
bambano #30512 üzenetére
ez oké, de kicsit továbbgurulva a cikkben, kifejti, hogy az nem baj, ha a fájljaid titkosítva vannak, mert azokat fel tudod oldani, amikor kellenek, addig meg védve vannak, de annak mi értelme, hogy le van titkosítva a /bin/bash-tól a /dev/nullig minden?
(#30513) debfan
titkosítsd, aminek félted a tartalmát. minden mást titkosítani erőforrás-pazarlás -
válasz
debfan #30510 üzenetére
Because the full disk is encrypted under full-disk encryption, a user who knows the disk decryption password has to enter it before anything else can proceed. But along with the user files, all the files the OS needs to run are also locked. A successful boot requires the whole block device to be unlocked, and once the disk is unlocked, it’s all open.
hogy ebben azért igencsak igaza van
teljesen fölösleges az egész lemezt mindenestől titkosítani, hogy aztán egy rendszerindításhoz fel kelljen oldanod és ezzel tökön is lőtted az egészet. -
-
-
-
-
-
-
válasz
cprogrammer #30475 üzenetére
Bármi előfordulhat, de maradjunk annyiban hogy 14 év alatt nem láttam még ilyet.
-
-
-
-
-
át szeretném irányítani egy Pi naplózását a home szerveremre, hogy ez se az SD kártyát koptassa, ha nem muszáj.
amit képtelen vagyok elérni (mert nyilván valami hülyeségen elsiklok), hogy ne ömlesztve vegye át egy fájlba a naplózást a szerver.
mert ugye van a syslog, meg az auth.log, meg a kern.log és társai, de ezek egy fájlba folynak össze a szerveren, holott az lenne az ildomos, hogy ugyanúgy szeparálva jelennének meg, mint a Pi-n.rsyslog és Debian fut mindkét eszközön
A Pi-n a következő módosult:
az /etc/rsyslog.conf végére biggyesztettem, hogy*.* @szerverIpje:514
ebben mondjuk van egy ilyen rész, hogyauth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
és úgy érzem, hogy valahol itt lesz a kutya elásvaA szerveren meg annyi történt, hogy
/etc/rsyslog.d/10-remote.confModLoad imudp
$UDPServerRun 514
$AllowedSender UDP, otthoniAlhálózatom/24
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/.log"
*.* ?RemoteLogs
& ~most így létrejön egy .log nevű fájl a /var/log/remote/%HOSTNAME% mappában és abba kerül minden
-
-
válasz
bambano #30364 üzenetére
Lehet, de egyrészt ilyen nem volt beállítva, másrészt igen valószínűtlen hogy pont azt a 600+ torrentet töröljék, ami nálam seedben volt.
Igazából ez lett gyanús, miután sehol nem volt semmi hibaüzenet vagy napló, ami nyomra vezetett volna, hogy hová lettek az adatok és miért pont az tűnt el, ami.
Beléptem a torrentbe és az tűnt fel hogy nem az van hogy 600-szor ki van írva hogy "missing files", hanem hogy tök üres az egész... 0 betöltött torrent. -
-
válasz
bambano #30312 üzenetére
csak hogy meglegyen a follow-up...
egyszerű LVM kötetbe volt szervezve 5 db 2TB-os HDD-m.
pár óránként jött a dmesg-be a fentihez hasonló üzenet, hogy most az ata5 esett le egy pillanatra, aztán az ata6, stb, de egy másodpercen belül már újra elérhető volt.
aztán egyik nap eltűnt 4TB-nyi adat, ezen felbuzdulva úgy láttam, hogy igazad volt*, és ez így nem mehet tovább, viszont gyanús volt, hogy egyébként a lemezek jók, a hiba máshol lesz.
lementettem mindent a kötetről, és az egészet átszerveztem egy ZFS kötetté, egész pontosan RAIDZ1-é (ami kb RAID5-nek feleltethető meg, egy lemez kiesését tolerálja). Azóta egyetlen esetben sem jött elő a fenti hibaüzenet.
úgy gondolom, hogy a SATA vezérlő nem tudott valamit elég gyorsan és / vagy jól csinálni, amire az LVM-nek igénye volt, aztán időnként feladta, és eldobta a lemezt, a ZFS meg talán hatékonyabb és nem fut bele ugyanabba a korlátba.* a torrentkliens webfelülete nem volt lejelszavazva, szerintem ott jött be valaki vagy valami, és egyszerűen kitörölte amit talált, mert kizárólag a seedben lévő dolgok tűntek el minden hibaüzenet nélkül.
-
-
-
lehet valahogy az egérmozdulatokat eseményként értelmezni?
tehát pl amíg mozog az egér X irányba, addig fusson le ez. ha megállt, akkor az, ha -X irányba, akkor amaz. -
-
-
-
"iperffel gyönyörűen megvan a kettő közt a gigabit."
-
smb3_11
[root@Echo-Five /]# smbstatus
Samba version 4.9.5-Debian
PID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
24697 lenry lenry 192.168.94.100 (ipv4:192.168.94.100:49670) SMB3_11 - partial(AES-128-CMAC)
-
-
-
-
válasz
bambano #30260 üzenetére
read raw
megwrite raw
opciókat belevettem, meg párat kivettem, amire azt írták, hogy gondot okozhat, így most sikerült 500 MBps környékére feltornászni.amúgy tuti, hogy valami triviális fasságon bukik el a dolog, mert a céges gépem egy semmi extra i3 Arch Linuxszal, és fut azon is egy Samba, és ha fel kell másolni valamit egy Windows kliensre, az gond nélkül 970-980 MBps, pedig most annak is néztem a konfigját, a globalban semmi nincs, ami ne lett volna az alapbeállítás része.
-
válasz
bambano #30258 üzenetére
Windows
C:\Users\lenry>netsh interface tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 1000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 4
Fast Open : enabled
Fast Open Fallback : enabled
HyStart : enabled
Pacing Profile : off
Linux
lenry@Echo-Five:/$ cat /proc/sys/net/ipv4/tcp_window_scaling
1
nincs ezen mit állítani
-
samba kérdésem van.
van a NAS-om, meg a gépem. előbbin Debian fut, utóbbin Win10. kettő közt egy Mikrotik hap ac2.
iperffel gyönyörűen megvan a kettő közt a gigabit.
ha viszont le szeretnék valamit másolni a NAS-ról a gépre, akkor a kezdeti lendületet jelentő pár másodperc után a sebesség beáll egy stabil 250 megabit környékére és ottmarad.
a NAS-ban nem látszik semmi komolyabb terhelés. sem az iotop, sem a htopban nincs kiugró semmi. a hdparm 100MB/s körüli eredményeket ad vissza szekvenciális olvasásra (pont amire szükségem van)
a Windowsban sem látszik hogy valahol leugrana a mutató a számlapról. a Mikrotikben sem.tehát maradt a samba.
mit lehetne azon tekerni, hogy ne ilyen szánalmas teljesítményt nyújtson? -
-
volt ez az esetem a múlt hétvégén és mérsékelt sikernek nevezném csak az eredményt. szerintetek mi volt a hiba?
-
-
-
-
-
-
-
-
-
Ha windows 10 akkor WSL-el talán megoldható a dolog.
hogyan?
mármint úgy, hogy a legegyszerűbb mindenki is megértse a működését, ne rontsa el, ne kelljen parancsokat gépelni, és ne legyen bonyolultabb a jelenlegi Ctrl-C - Ctrl-V-nélPlusz a nem változó dolgokra hasznos lehet egy sima tar.gz
ez jelenleg úgy néz ki, hogy a kolléga végzett a munkájával, akkor felmásolja a projektet szerverre, hogy a következő kolléga folytatni tudja a következő fázissal. ennél bonyolultabb műveletet senki nem lesz hajlandó végezni, ezért kell vagy szerveroldalról megoldani, vagy kliensoldalról úgy, hogy a usernek ne legyen vele dolga.De amúgy mi ez?
Unity3D projektek -
van egy 32 szálas robocopy batch, ami egy bizonyos almappa másolásait intézi és az gyors, de az a mappa relatív sűrűn használt és nem változik, ezért lehetett rá batchot írni, de a megosztás többi részére ez nem megoldás, az meg sajnos irreális elvárás, hogy a kollégák tanuljanak meg cmd-t használni
viszont ha valahogy transzparensen meg lehetne oldani, hogy egy Ctrl-C - Ctrl-V is tudjon több szálon másolni, az nagyon fasza lenne -
válasz
bambano #28572 üzenetére
nem tudod-e megoldani, hogy a sok apró fájlt tartalmazó projektek egy helyre kerüljenek
de, ezért van ez a szerveraz ext4 nem túl boldog, ha sok fájl van.
kollégám BSD párti, ő a ZFS-t propagálja, hogy abban van beépített cache (ZIL), amit egyáltalán nem vetek el mint B terv, de ismeretlen terep számomra a ZFS, úgyhogy ha ennél kevésbé drasztikus módszerrel is meg lehetne oldani az nem volna baj...Samba aio-t néztem, de az Debianban egyelőre a testing repoban van, gondolom okkal
-
van egy szerver, Debian fut rajta, elsődleges szerepe a Samba megosztás.
van benne 4x4TB HDD, RAID10-ben, ext4 fájlrendszerrel.a probléma vele, hogy a kollégák, akik fel-le másolgatnák a projekteket, olyan projekteken dolgoznak, amik többtízezer pár bájtos fájlt (is) tartalmaznak. értelemszerűen ettől nem lesz gyors a művelet.
kérdés akkor, hogy hogyan lehetne ezen segíteni?
nyilván a "cseréld SSD-re" nem játszik annak költségei végett és a klienseken is marad a Windows, ezért ha van mit szoftveresen tweakelni (azt is inkább szerveroldalról), akkor arra érdekelnének ötletek.gondolkodtam a bcache-en, hogy betennék 1-2 kisebb SSD-t, de nem tudom mennyit segítene ez, mert nem mindig ugyanazt másolgatják.
szerintetek?
-
-
-
-
olyat szeretnék hogy:
van egy Samba megosztás, aminek egy bizonyos mappájának minden bekerülő fájljának jogait automatikusan 555-re kellene módosítani. a mappák és almappák meg nem lenne baj, ha 777-re kerülnek, de ez opcionális. -
válasz
bambano #28072 üzenetére
nem backup, vagy ilyesmire kell
az eredeti probléma:
amit a kolléga beránt bármilyen eszközről (főleg Android) Drive-ba, azt jelenjen meg a szerver egy mappájában és vica versa.mivel Androidon a Google Drive a legkézenfekvőbb és legegyszerűbb, ezért az én oldalamat (a szerver) kell ahhoz igazítani.
a kollégák kényelme mindenek felett -
-
tudtok nekem olyan Google Drive klienst, ami
- CLI
- képes csak kijelölt almappát szinkronizálni
- figyeli a lokális fájlokat
- figyeli a remote fájlokat
- változás esetén szinkronizál
?eddig csak olyanokat találtam az első két követelményt tudja, ezért megírtam egy inotify-ra épülő scriptet, ami figyeli a lokál mappát, egy daemont, ami futtatja a scriptet, egy cronjobot ami x időközönként szinkronizál (mert fogalmam sincs hogyan figyeltessem a távoli mappát) és épp azon gondolkodtam, hogy hogyan kellene valami lockfile-al megakadályozni, hogy a cron meg a script egyszerre dolgozzon, amikor bevillant, hogy "nincs az az isten, hogy én vagyok az első, akinek erre szüksége lenne", szóval biztos vagyok benne, hogy ezt valaki már megoldotta...
-
megjelent az 5.0-s Linux kernel
-
-
-
-
Samba kérdés
a szerveremen fut egy Transmission
a letöltött fájlok és mappák tulajdonosa adebian-transmission
nevű user, a csoportja pedig alenry
nevű csoport, amiben nyilván benne van a fenti user meg alenry
user is.a Sambát eddig guestként értem el, ami egyszerű, de a Transmission által létrehozott mappákat így nem tudtam módosítani, ezért most létrehoztam egy lenry nevű Samba-usert, amivel ugyanúgy nem tudom módosítani a fájlokat, ezért nyilván valamit nem jól csináltam.
nem egészen világos, hogy a lenry usernek és a lenry samba-usernek van-e valami köze egymáshoz, de gyanítom nincs és ez lesz a probléma gyökere, de mi a megoldás?
-
-
Új hozzászólás Aktív témák
Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Ubiquiti hálózati eszközök
- Vicces képek
- Medence topik
- One otthoni szolgáltatások (TV, internet, telefon)
- iPhone topik
- Ingatlanos topic!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Poco F6 5G - Turbó Rudi
- További aktív témák...
- Azonnali készpénzes Intel i3 i5 i7 i9 12/13/14 gen processzor felvásárlás személyesen / csomagküldés
- ASUS Radeon RX 7600 V2 Dual OC 8Gb - Aqua gari 26.12.12 ig
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- DELL Precision 7540 - Intel Core i9-9980HK, RTX 3000 (nagyon erős GPU-val)
- REFURBISHED és ÚJ - HP USB-C/A Universal Dock G2 docking station (5TW13AA) (DisplayLink)
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest