-
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
-
Osiris
őstag
válasz
bambano
#27206
üzenetére
Ezen a vonalon sikerült megtalálni a hibát:
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists.
Ez alapján ezt találtam:
/etc/profile.d/sshpasswd.shBenne pedig a service parancs:
if service ssh status | grep -q running; then
check_hash
fi
...kiegészítettem az elérési úttal ( /usr/sbin/ ).Ezek szerint ez a szkript előbb lefut mint ahogy a PATH betöltődik.
Köszönet a tippért.
-
Osiris
őstag
A service nálam:
$ll /usr/sbin/service
-rwxr-xr-x 1 root root 9270 Sep 5 14:35 /usr/sbin/service
...futtatható mindenki számára, ráadásul a .bashrc-ben egyszer sem fordul elő ez a parancs.
Emiatt akadtam el a hiba keresésével.
Honnan futtat még parancsokat a linux login alkalmával a .bashrc-n kívül? -
Osiris
őstag
Sziasztok,
Terminálra bejelentkezéskor közvetlenűl mielőtt megkapom a promptot kapok egy ilyen hibaüzenetet:
-bash: service: command not foundKérdésem: Hogyan lehet kinyomozni, hogy mi okozza ezt?
.bashrc-ben logokban körülnéztem, de semmi. Ha jól emlékszem egy egyszerű "apt upgrade" óta van ez a hiba.
-
Osiris
őstag
Postfix mail.log-ban vannak Message-ID nevű azonosítók:
Message-ID: <CAK=rMt7E4qYeR9veqTKd0ACP-YhAfhw73tGcMfxms43RatDc0w@mail.gmail.com>Ezen Message-ID-k megtalálhatóak az e-mail fájlokban a mail szerveren és így elvileg a log alapján tartalomra keresve meg lehetne találni, hogy a logbejegyzés melyik levélhez tatozik. Viszont én most azt tapasztalom, hogy a log-ban található azonosító nem minden esetben ugyanaz ezekben az e-maileket tartalmazó szövegfájlokban mint a logban, a levélben valami egészen más karaktersor van (a formátuma ugyanaz).
Van valami módszer, hogy a log alapján visszakeressem a leveleket a szerveren?
-
Osiris
őstag
Sziasztok!
Bashban szeretnék fájlt keresni tartalom alapján és a fájlnevet a teljes elérési úttal visszakapni. Az alábbi parancsmegfelelő lenne:
root@mail:~# find /home/vmail/domain.hu/user -type f -print0 | xargs -0 grep --line-buffered -l "kk515eqcatswcvegvg57lf7r.1488271823679@email.android.com"
/home/vmail/domain.hu/user/cur/1488271826.M7376P25180V000000000000FC00I00000000008811C1_0.mail.domain.hu,S=4802:2,Viszont ha ugyanezt a parancsot egy bash scriptben akarom használni, akkor nem kerül a változóba semmi:
emailfile=$(find /home/vmail/domain.hu/$user -type f -print0 | xargs -0 grep --line-buffered -l "$message_id")Hogyan kéne átírni hogy működjön?
-
Osiris
őstag
Automatizált bash scriptből szeretnék futtatni tar parancsot, ami az archiválandó könyvtárak listáját egy tömbből kapja. A probléma az, hogy a könyvtárak között van amelyik tartalmaz space-t és ilyenkor a tar hibaüzenetet ad (csak ha a parancsfájlból hívom
):Így áll össze a tar parancs:
for (( k=0; k<$thossz; k++))
do
if [ `cat "${BackUpFiles[$k]}"` = "$1" ] || [ 'heti' = "$1" ];
then
BACKUPDIRLIST[ $k ]="\"`dirname "${BackUpFiles[$k]}"`\""
unbuffer echo `dirname "${BackUpFiles[$k]}"`
fi
done
TARCOMMAND="tar cf $BACKUPDIR/Backup_$TIMESTAMP.tar ${BACKUPDIRLIST[*]}"A $BACKUPDIRLIST-be azok a könyvtárak kerülnek amik tartalmaznak egy 'BaCkUp' nevű fájlt aminek a tartalma 'heti'.
A $TARCOMMAND tartalma ez lesz:
(M)tar cf /home/backupadmin/backup/Backup_2015_46.heti.tar "/home/share/shared/Dokumentumok" "/home/share/shared/Knowledge_base" "/home/share/shared/ISO-9001-2001" "/home/share/shared/Bak" "/home/backupadmin/backup/openkm_Repo_backup" "/home/backupadmin/backup/mantis_DB_backup" "/home/backupadmin/backup/redmine_DB_backup" "/home/backupadmin/backup/workspace_DB_backup" "/home/management/management/CEGES/Projekt" "/home/management/management/CEGES/Marketing" "/home/management/management/CEGES/HR" "/home/management/management/CEGES/Események" "/home/management/management/CEGES/Logó" "/home/management/management/Ebben vannak spacek" "/home/management/management/CEGES GDrive"Ha ezt a parancsot beírom a paranccsorba, hiba nélkül lefut, de ha a script hívja meg (így):
(M)echo "`unbuffer $TARCOMMAND`"akkor (szerintem) a space-eket tartalmazó könyvtárnevek miatt elszáll:
(M)tar cf /home/backupadmin/backup/Backup_2015_46.heti.tar "/home/share/shared/Dokumentumok" "/home/share/shared/Knowledge_base" "/home/share/shared/ISO-9001-2001" "/home/share/shared/Bak" "/home/backupadmin/backup/openkm_Repo_backup" "/home/backupadmin/backup/mantis_DB_backup" "/home/backupadmin/backup/redmine_DB_backup" "/home/backupadmin/backup/workspace_DB_backup" "/home/management/management/CEGES/Projekt" "/home/management/management/CEGES/Marketing" "/home/management/management/CEGES/HR" "/home/management/management/CEGES/Események" "/home/management/management/CEGES/Logó" "/home/management/management/Ebben vannak spacek" "/home/management/management/CEGES GDrive"
tar: "/home/share/shared/Dokumentumok": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/share/shared/Knowledge_base": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/share/shared/ISO-9001-2001": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/share/shared/Bak": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/backupadmin/backup/openkm_Repo_backup": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/backupadmin/backup/mantis_DB_backup": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/backupadmin/backup/redmine_DB_backup": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/backupadmin/backup/workspace_DB_backup": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/CEGES/Projekt": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/CEGES/Marketing": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/CEGES/HR": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/CEGES/Események": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/CEGES/Logó": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/Ebben: a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: vannak: a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: spacek": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: "/home/management/management/CEGES: a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: GDrive": a következő függvény meghiúsult: stat: Nincs ilyen fájl vagy könyvtár
tar: Kilépés hibaállapottal a korábbi hibák miattMit lehet ezzel kezdeni, hogy rendesen lefusson a tar?
-
#22691
Osiris
őstag
Cyber_Bird
#22690
Osiris
őstag
válasz
Cyber_Bird
#22690
üzenetére
Sőt, csak azt nézhetek, mert a kimenete a távoli szerverre megy és a helyi gépen csak üres kimenetet ad.
-
#22689
Osiris
őstag
Cyber_Bird
#22688
Osiris
őstag
válasz
Cyber_Bird
#22688
üzenetére
sshpass tökéletes. Köszönöm!
# sshpass -p 'Password' ssh -o StrictHostKeyChecking=no user@11.22.33.44 exit
...és ha a kimenetben nem szerepel a "Permission denied", akkor sikeres.
-
Osiris
őstag
Ja, hát ez egyértelmű. Valamiért abban a hsz.-ben sikerült hülyeségeket beszélnem.
A lényeg (és az értelmes dolog) az lett volna, hogy primary 2. partíció a lemez elején elhelyezett swap, és a primary 1. partició a swap után maradó lemezterületen exFAT. Így a windows is felismerte volna és a swap is működött volna. (...de végül az exFAT kezelés linux alatti overheadje miatt elvetettem ezt és lett az egész lemez 1db primary ext2 partíció swap file-al.) -
Osiris
őstag
válasz
Osiris
#22674
üzenetére
..szóval: Nem lehet exFAT vagy más olyan fájlrendszeren swap fájlt használni ahol a fájlra vonatkozó jogok nem beállíthatók. (USB 2.0 HDD-re kell hordozható, win és linux alatt is működő megoldás)
Most azon gondolkozom, hogy az lehet e megoldás, hogy van két partíció:
-primary 1 (a swap fájlt tartalmazó ext2 partíció mögött a lemez végéig) és
-primary 2. ami linux ext2 (a lemez elején).Így windows alatt a win az exFAT-ot simán felcsatolja és eléri, de azt nem tudom még, hogy a linux ezt az ext2-n tárolt swap-et megeszi e? (Mert a távoli gép amin próbálokozm épp nem jött vissza egy újraindításból.)
-
Osiris
őstag
Lehet exFAT fájlrendszeren swap fájlt használni?
Odáig simán eljutok, hogy létrehozom a swap.file -fájlt. Majd mkswap-al azzá is teszem, de a swapon már problémázik a jogok miatt (amiket exFAT-on nem lehet megváltoztatni):
$ sudo swapon /home/osmc/shared/swap.file
swapon: /home/osmc/shared/swap.file: insecure permissions 0755, 0600 suggested.
swapon: /home/osmc/shared/swap.file: swapon failed: Invalid argument
$ ls -la ./swap.file
-rwxr-xr-x 1 root root 192000 Aug 31 12:20 ./swap.fileAz hogy a swap egy külső felcsatolt hdd-n van exFAT filerendszeren, az azért van, mert a rendszer SD kártyán fut. Lehet valahogy ignorálni a swap fájl permission-jait?
-
Osiris
őstag
válasz
_Dumber_
#22498
üzenetére
Az ok az lehet, hogy hiányzik egy masquarade a shorewall konfigból (be kéne állítani, hogy a rajta áthaladó, a belső háló felé irányított csomagokra saját magát állítsa be forrás címként).
Most ez történik mikor a belső hálóból a kamerát akarod elérni:
-a kliens a kérést a saját ip címéről (mint forrás címről elküldi) a külső ip címre (amit a domain visszaad) mint cél címre.
-a kérést a routered továbbítja a kamerához, de a forrás ip-t nem változtatja meg (nem maszkolja) a saját ip címére.
-a kamera a beérkezett kérésre a választ a kérés forrás ip címére küldi (vagyis közvetlenül a kliensnek) és a válasz forrás ip címe a kamera ip címe lesz.
-a kliens a választ a külső ip címről várja (amit ő a kérés céljának megjelölt), így a kamerától kapott választ eldobja.A megoldás az lenne, hogy a router a kérést a saját nevében (saját ip címét forrásként beállítva) küldené tovább a belső hálóra a címzettnek, így a válasz is rajta keresztül menne vissza és a kliens így fel tudná dolgozni.
Ezt a módszert "hairpin nat"-nak is nevezik erre keress rá.
-
Osiris
őstag
válasz
Osiris
#22481
üzenetére
Közben úgy tűnik, hogy a teljes memória mérete lecsökken a BADRAM bekapcsolása esetén, vagyis a dolog akár működhet is. Egyelőre lefuttatok két memória tesztet (memtester) amit a rendszer működése közben is lehet futtatni (nem olyan mint a memtest86+): egyet kikapcsolta és egyet bekapcsolt BADRAM-mal. Ha minden jól megy, akkor csak a kikapcsolt esetén lesz hiba és akkor elhiszem, hogy működik és mehet élesbe.
-
Osiris
őstag
BADRAM:
Szóval lefutott a memtest:
Mivel ez elvileg a BADRAM-nak megfelelő hiba formátum, így be is írtam a /etc/default/grub fájlba, ami most így néz ki:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
GRUB_BADRAM="0x91277914,0xfffffffc,0x8ca77914,0xfdfffffc,0x94947914,0xfffffffc"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"Természetesen az upgrade-grub is megvolt.
A dmesg kimenetében semmi nem látszik abból, hogy ezeket a memóriacímeket kikerülné.
Most akkor mi van? Rossz formában van a címzés? (Ubuntu 14.04 x64 server) -
Osiris
őstag
A ram már ki van szedve, de így nem maradhat: virtualizált gépek vannak ezen a szerveren és kevés a memória. Sajnos nincsenek jó tapasztalataim a ram kompatibilitással kapcsolatban, az új modulokon nagyobb kapacitású csipekből van kevesebb, próbálkoztam ilyen új modullal, de nem ment együtt a maradék 3db 8GB-os modullal. Persze próbálok használtan ugyanilyen modult venni, csak még nem jött össze.Addig is érdekes téma ez a "badram". A hibás modul egyetlen helyen hibás, így szerintem nem lenne gáz így tovább használni, annyira nem kritikus a szerver és minden mentve van.
-
Osiris
őstag
válasz
bambano
#22466
üzenetére
Rengeteget keresgéltem és azt találtam, hogy a 64 bites ubuntuban a badram grub paramétert nem igazán tudja senki milyen formában kell megadni: a 32bites címekkel nem lehet használni.
Én még nem jutottam oda, hogy ki próbáljam a badram paraméter használatát, de holnap arra is sor kerül. Remélem nekem sikerül a memtest által megadott memóriacímeket megfelelően megadnom (azt már tudom, hogy a memtest tud direkt ilyen formátumban visszaadni hibás címeket).Amit kipróbáltam és valamit csinál az a kernelparaméterként megadott "memtest=4". Ezt szintén a grub-ban adom meg és a dmesg-ben valóban látszik, hogy a boot elején leteszteli a modulokat, de amit a memtest86+ is csak a 7-es tesztben talál meg azt ez meg sem találja.
Holnap remélem a badrammal sikerül megoldani ezt a dolgot.
-
Osiris
őstag
Van egy szerver 32GB rammal (4x8GB DDR3), az egyik modul egyetlen helyen konstans hibázik. Állítólag linux alatt a kernelnek meg lehet mondani valahogy, hogy ezt a részt ne használja. Én még sosem próbáltam ilyet csinálni, de most mivel nem tudok csere modult szerezni és nagyon kéne a memória, így erre a megoldásra kényszerülök. Tudtok egy jó leírást, hogy ubuntu alatt mi ennek a módja, vagy csinált már ilyet valaki? Jól jönne a segítség.
-
Osiris
őstag
Egy windows xp megosztás fel van csatolva linux alá, a linuxos gép sambával tovább osztja ezt a megosztást a hálózaton. A samba szerver a megosztáshoz teljes hozzáférést enged és a windows xp is a megosztásához. Az eredmény mégis az, hogy a samba által tovább osztott xp-s megosztást nem lehet írni csak olvasni.
Mi a franc lehet a baja? A linuxon is csak a root tudja írni az xp-s megosztást. -
Osiris
őstag
Red Hat 6 alatt a rendszer a hostnevet nagyon szépen hozzárendeli a dhcp-től kapott ip címhez, ami nagyon hasznos, mikor ezen a külső ip-n akarok egy szervert üzemeltetni és nem a loopbac-en.
Viszont szépen betettem a Red Hat alá a CentOS repo-t és frissítettem a rendszert. Azóta a hostname a 127.0.0.1-et jelenti és sehogy nem jövök rá, hogyan lehetne a hostnév az éppen aktuális külső IP cím.
Tudja valaki mi erre a megoldás? (Fontos, hogy a (virtuális) gép hordozható maradjon, vagyis a dhcp-n kiosztott IP cím legyen a hostnévhez társítva és nem egy fix ip cím!) -
#16596
Osiris
őstag
MasterDeeJay
#16593
Osiris
őstag
válasz
MasterDeeJay
#16593
üzenetére
Hasonló problémám van egy multifunkciós eszközzel ami hp L7680. A digitális irattár nevű feature, ami szintén a hálózatra mentené a scannelt dolgokat, csak windowsos megosztással működik. A probléma ha jól emlékszem úgy jelentkezik, hogy mikor nem egyetlen oldalt scannel, hanem többet és egy pdf-be akarja menteni, akkor egyszerüen megáll és nem tudja menteni a dokumentumot.
Sajnos megoldást nem sikerült találni erre a problémára. Jelenleg egy win xp-t futtató virtuális gép szolgáltatja a megosztás a linux szerveren és ez a win-es megosztás van felcsatolva a scannerre, így megy... -
Osiris
őstag
Sziasztok,
Debian alapú RaspBMC (raspberry pi) linuxon szenvedek olyan problémával, hogy letöltéskor a "transmission-daemon" torrentkliens egy idő után leáll. A kernel.log-ban ilyenkor ezt a bejegyzést látom:
Feb 7 09:39:56 raspbmc kernel: Out of memory: Kill process 1253 (transmission-da) score 91 or sacrifice child
Feb 7 09:39:56 raspbmc kernel: Killed process 1253 (transmission-da) total-vm:56396kB, anon-rss:20kB, file-rss:780kBAzt értem, hogy elfogyott a memória, de azt nem , hogy miért. A régebbi RaspBMC kiadásoknál ilyen gondom nem volt (ugyanezen a hardveren). A ram tényleg elég kevés, de a swapben még bőven lenne hely:
free -m
total used free shared buffers cached
Mem: 121 109 12 0 0 59
-/+ buffers/cache: 50 71
Swap: 127 33 94Mi lehet az oka, hogy nem használ több swappet?
-
Osiris
őstag
válasz
Osiris
#12334
üzenetére
Úgy tűnik a grafikonokon maximum 24 órányi adat szerepelhet, így naponként kell külön grafikont készíteni. A parancs amit ki kell adni a ksar scp command menüben: sar -bBcdqrRuvwWy -I SUM -I XALL -n ALL -P ALL -f /var/log/sysstat/sa11 . Az sa11 fájlnévben a 11 helyén mindig az adott hónap adott napjának a száma van. Így minden adatot ki lehet nyerni ami jellemző az adott gép működésére.
-
Osiris
őstag
System Activity Report (sysstat/sar) segítségével gyűjtött adatokból a ksar segítségével készítenék grafikonokat. Az a problémám, hogy jelenleg a grafikonok mindíg az adott nap 0:00-tól kezdődnek és a lekérés időpontjáig tartanak. Hogy lehetne a kezdő időpontot úgy beállítani, hogy a grafikon pl az elmúlt 1 hétre vonatkozzon? Nem találok sehol infót erről.
Új hozzászólás Aktív témák
Hirdetés
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Assassin's Creed Shadows Collector's Edition PC
- 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!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Bomba ár! HP ProBook 450 G6 - i7-8GEN I 16GB I 256SSD I HDMI I 15,6" FHD I Cam I W10 I Gari!
- BESZÁMÍTÁS! ASUS Z390 i5 9500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA Thermaltake 500W
- Samsung Galaxy S23 Plus 256 GB Kártyafüggetlen 1Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest