-
Fototrend
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
-
#32114
Lenry
félisten
MasterMark
#32113
Lenry
félisten
válasz
MasterMark
#32113
üzenetére
ez egy rejtély akkor
-
#32112
Lenry
félisten
MasterMark
#32111
Lenry
félisten
válasz
MasterMark
#32111
üzenetére
ha a Ctrl-A-D működik, akkor a Ctrl-A-K-nak is kellene, az a kill screen parancs.
igaz, az megkérdezi, hogy biztos ki akarod-e lőni, szóval még egy Y-t (yes) nyomni kell
-
#32110
Lenry
félisten
MasterMark
#32109
Lenry
félisten
válasz
MasterMark
#32109
üzenetére
de most ki szeretnéd lőni a screent?
mert azt simán Ctrl-D-vel vagy Ctrl-A-K-val megteheted
és akkor tuti killelve lesz minden process, ami benne futott -
Lenry
félisten
válasz
BlackSoft
#31970
üzenetére
Én a biztonságosan, átláthatóan működő RAID lehetőségek
van egy IBM szerverünk.
2 SFF lemez fér bele, és csak a RAID vezérlőben létrehozott virtuáldiszket hajlandó továbbadni az OS-nek.
ez addig tök szuper, amíg az egyik HDD el nem kezdni megadni magát.
hogyan váltod ki? nem tudsz betenni még egy lemezt, mert nem fér.
nem tudod kivenni a régi lemezt és lemásolni róla az adatokat, mert semmi más nem olvassa, csak az IBM-es RAID vezérlő.na ez az eset óta tartom orbitális marhaságnak a hardveres RAID vezérlőket úgy, ahogy vannak, és azóta úgy veszek gépet, hogy az első kérdésem, hogy "át lehet-e flashelni a RAID vezérlőt IT módba?"
-
Lenry
félisten
válasz
Roxkex
#31937
üzenetére
cron résztől jónak tűnnek az időzítések, tehát annak kellene történnie, amit vársz.
Maga a script fájlal probléma nincs, mert direktbe manuálisan Én eltudom indítani.
a cron sokkal szűkebbre szabott környezeti változókkal dolgozik, mint egy user, simán lehet, hogy elhasal egy olyan bináris elérésén, ami a te PATH-odban benne van, az övében meg nincs.
javaslom kiegészíteni a sorok végét*/5 12-21 * * * /srv/*****/automationScripts/linux/+***--***.sh > /tmp/logMasik.txt
hogy lásd mi történik, illetve mi nem történik -
-
Lenry
félisten
-
Lenry
félisten
frissítettem Debian11-re, azóta nem hajlandó működni a gépben lévő SATA kártya.
ha régi 4.x-es kernelt indítok, azzal jó (akkor más nem működik), de ha a frissen telepített 5.x-est, akkor meg sírva fakad a rendszer
mit lehet ezzel kezdeni?
ASMedia 1062-es SATA vezérlő -
Lenry
félisten
válasz
bambano
#31574
üzenetére
de ugyanúgy a saját pl lenry.hu-s címemről, meg minden?
azért kérdem, mert pár hónapja egy unalmas délután én is összeraktam a saját levelezőszerverem, és ugyanott akadtam el, mint a kolléga föntebb, de ezután rá is hagytam, annyira nem érdekelt a dolog...ha viszont megoldható, akkor lehet, hogy előveszem ismét a projektet
-
-
Lenry
félisten
válasz
Shyciii
#31517
üzenetére
persze, simán.
én pl az otthoni UPS-emhez állítottam be pont nemrég, hogy áramszünet (vagy bármi más kezelt esemény) esetén küldjön egy emailt.
Debianon
msmtp-t használok, mellette még amailxés as-nailvan feltelepítve, így a mail parancs az msmtp-n keresztül fogja küldeni az üzenetet.pl gmailen keresztüli üzenetküldéshez annyi kell, hogy létrehozod az
/etc/msmtprcfájlt a következő tartalommal:defaults
auth on
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
account gmail
host smtp.gmail.com
port 587
from FeladóSzépenFormázottNeve
user emailCím
password Jelszó
account default : gmail
ennyi
(illetve a Google-fiókban kapcsold be a Kevésbé biztonságos alkalmazások hozzáférését)aztán üzenetet pedig pl a következő paranccsal küldesz
echo "Az üzenet" | mail -s "Tárgy" címzett@domain.tld -
Lenry
félisten
válasz
kraftxld
#31479
üzenetére
passz, nincs ezzel tapasztalatom, csak a kiírt hibaüzenet alapján úgy gondolom, hogy a grubon már túljutott, csatolná fel a root meghajtót, csak a megadott /dev/vg_root nem létezik, ahogy az a screenshoton is látszik, hogy nem látszik.
ha tudsz, adj ki egy
lsblkparancsot, az kilistázza, hogy milyen meghajtókat és partíciókat lát a rendszer, abból be kell, hogy tudd azonosítani hogy melyik lehet a rendszerpartíció, aztán az/etc/fstabfájlban módosítsd a/-re vonatkozó sort
vagy ha biztosra akarsz menni, akkorblkidparancs (vagy ha az nem létezik, akkorls -l /dev/disk/by-uuid/), és az ott visszakapott UUID-t másolod be az fstabba, mert az biztosan nem változik, míg a/dev/sda,/dev/sdb, stb nem garantálható, hogy mindig ugyanazt a meghajtót jelölik -
Lenry
félisten
én külön nem állítottam semmit sem a Docker, sem a szóbanforgó container beállításai közt, sőt, azokra az IP tartományokra egyáltalán semmilyen szükség nincs, ott a host IP-je, ami 9.x, illetve a Docker által használ belső 172.x.x.x. mire hoz létre 192.168.x.x subneteket?
ez alapján úgy látom, hogy a Docker olyan maszkokkal és hálózati beállításokkal dolgozik, amilyet ő szeretne
-
Lenry
félisten
root@docker2:/home/lengyelr# ping 192.168.50.252
PING 192.168.50.252 (192.168.50.252) 56(84) bytes of data.
From 192.168.48.1 icmp_seq=1 Destination Host Unreachable
From 192.168.48.1 icmp_seq=2 Destination Host Unreachable
From 192.168.48.1 icmp_seq=3 Destination Host Unreachable
itt lesz a hiba úgy látom... a docker egy belső bridge-ére fut a kérés, ezt kijavítva rögtön magához is tért.
root@docker2:/home/lengyelr# ip route add 192.168.50.0/24 via 192.168.9.1 dev eth0
root@docker2:/home/lengyelr# ping 192.168.50.252
PING 192.168.50.252 (192.168.50.252) 56(84) bytes of data.
64 bytes from 192.168.50.252: icmp_seq=1 ttl=63 time=0.496 ms
64 bytes from 192.168.50.252: icmp_seq=2 ttl=63 time=0.636 ms
64 bytes from 192.168.50.252: icmp_seq=3 ttl=63 time=0.609 ms
köszi a segítséget mindkettőtöknek
-
Lenry
félisten
mi nyűgje lehet annak a Debiannak, ami egyszerűen nem hajladó felvenni a kapcsolatot bizonyos alhálózatokból érkező kérésekre? se pingre, semmire. ő maga a 192.168.9.0-ban van. 1.0-ból pl érhető. de 50.0-ból nem.
minden más, ugyanabban a 9.0-ban lévő gép elérhető, szóval a hálózat szempontjából rendben lévőnek gondolom a helyzetet, valószínűleg a konkrét gép makacskodik, csak hát fut rajta egy csomó olyan szolgáltatás, amit el kellene érnie a többi gépnek, aztán így meg most nem...a routing táblája szerintem úgy néz ki, ahogy annak ki kell
root@docker2:/home/lengyelr# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.9.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.9.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.48.0 0.0.0.0 255.255.240.0 U 0 0 0 br-6832b726505d
192.168.64.0 0.0.0.0 255.255.240.0 U 0 0 0 br-d07d09b13385
192.168.96.0 0.0.0.0 255.255.240.0 U 0 0 0 br-92c69a9c4d51mi mást nézzek?
-
Lenry
félisten
válasz
Predatorr
#31160
üzenetére
Szerintem lépj egyet hátrébb. Mire kell neked a Linux? Mert haWindowsos programokat akarsz futtatni, arra a Windows való.
Drivereket fölösleges keresgélni, nagyjából minden futni fog és működni (a TV tuner mondjuk pont kivétel lehet)
"Olvastam, hogy ilyen hiba esetén alaplapon kell állítani"
Mit kell állítani? -
Lenry
félisten
válasz
bambano
#31138
üzenetére
mindkét swapfájl a /-ben van, az meg SSD.
egyébként valószínűleg tényleg felszabadítgatja a dolgokat, de még van 5GB a kezdeti 8-ból.
mondjuk az se világos hogy alapból minek swappel, van még vagy 20GB szabad RAMha éppen nem használt szolgáltatásokat leállítasz ideiglenesen.
én csak az infrastruktúrát adom, azt se tudom mit csinál ez a gép, nemhogy leállítsak rajta bármit.
mindegy, elindítottam screenben, reggelig ráér.köszi a segítséget
-
Lenry
félisten
az egyik rendszer kinőtte a swapfájlját, semmi gond, létrehoztam egy nagyobbat, beaktiváltam, látja, eddig szuper.
viszont a régi, kisebbet kidobnám, persze nyilván anélkül, hogy a benne lévő akármi elveszne.
ha egyszerűen azt mondom, hogyswapoff /swap.img, akkor a rendszer lesz annyira okos, hogy átlapátolja a dolgokat a másik fájlba? -
-
Lenry
félisten
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
-
Lenry
félisten
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
-
Lenry
félisten
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 -
Lenry
félisten
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)
-
Lenry
félisten
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.
-
Lenry
félisten
nem tűnik egy űrtechnológiának a logrotate, mégse működik jól nálam
[root@Echo-Five logrotate.d]# cat remote
/var/log/remote/*/*
{
rotate 90
daily
missingok
compress
}ez nálam azt csinálja, hogy rekurzívan hülyére csomagol dolgokat és ez lesz az eredmény
csak ebben a mappában 60.000 fájl van.miért?
-
Lenry
félisten
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. -
Lenry
félisten
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 -
Lenry
félisten
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.
-
Lenry
félisten
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. -
Lenry
félisten
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 -
Lenry
félisten
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 -
Lenry
félisten
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
-
Lenry
félisten
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 -
Lenry
félisten
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. -
#30476
Lenry
félisten
cprogrammer
#30475
Lenry
félisten
válasz
cprogrammer
#30475
üzenetére
Bármi előfordulhat, de maradjunk annyiban hogy 14 év alatt nem láttam még ilyet.
-
Lenry
félisten
á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
-
Lenry
félisten
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. -
Lenry
félisten
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Fejhallgató erősítő és DAC topik
- Apple MacBook
- Ubiquiti hálózati eszközök
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Androidos tablet topic
- sziku69: Fűzzük össze a szavakat :)
- Napelem
- Vezeték nélküli fejhallgatók
- Mesterséges intelligencia topik
- Kezünkben a OnePlus 15 és az Oppo Find X9-ek
- További aktív témák...
- AKCIÓ! Sony PlayStation 5 825GB digital extra fejhallgatóval garanciával hibátlan működéssel
- Apple iPhone 12 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- FIFA 16 Playstation 4
- BESZÁMÍTÁS! ASRock B450M R5 5600 16GB DDR4 512GB SSD RTX 3070 8GB SilentiumPC Signum SG1 750W
- Dell Latitude 5420 14" Touchscreen i5-1135G7 16GB 512GB 1 év garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest