Linux-haladó

Sziasztok!

Van egy Amazon EC2-es virtuális gépem (t2.medium eu-west-1a), amihez fel van csatolva egy kötet (Elastic Block Store).
Az alábbihoz hasonló hibaüzeneteket kapok a konzolra. Mi a fene lehet ez?


MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
Cannot find module (SNMPv2-TC): At line 10 in /usr/share/snmp/mibs/UCD-DLMOD-MIB.txt
Cannot find module (SNMPv2-SMI): At line 34 in /usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Cannot find module (SNMPv2-TC): At line 37 in /usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Did not find 'enterprises' in module #-1 (/usr/share/snmp/mibs/UCD-SNMP-MIB.txt)
Did not find 'DisplayString' in module #-1 (/usr/share/snmp/mibs/UCD-SNMP-MIB.txt)
Did not find 'TruthValue' in module #-1 (/usr/share/snmp/mibs/UCD-SNMP-MIB.txt)
Unlinked OID in UCD-SNMP-MIB: ucdavis ::= { enterprises 2021 }
Undefined identifier: enterprises near line 39 of /usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Did not find 'DisplayString' in module #-1 (/usr/share/snmp/mibs/UCD-DLMOD-MIB.txt)
Did not find 'ucdExperimental' in module UCD-SNMP-MIB (/usr/share/snmp/mibs/UCD-DLMOD-MIB.txt)
Unlinked OID in UCD-DLMOD-MIB: ucdDlmodMIB ::= { ucdExperimental 14 }
Undefined identifier: ucdExperimental near line 13 of /usr/share/snmp/mibs/UCD-DLMOD-MIB.txt
Cannot find module (MTA-MIB): At line 0 in (none)
Cannot find module (NETWORK-SERVICES-MIB): At line 0 in (none)
Cannot find module (SNMPv2-TC): At line 15 in /usr/share/snmp/mibs/UCD-DISKIO-MIB.txt
Did not find 'DisplayString' in module #-1 (/usr/share/snmp/mibs/UCD-DISKIO-MIB.txt)
Did not find 'ucdExperimental' in module UCD-SNMP-MIB (/usr/share/snmp/mibs/UCD-DISKIO-MIB.txt)
Unlinked OID in UCD-DISKIO-MIB: ucdDiskIOMIB ::= { ucdExperimental 15 }
Undefined identifier: ucdExperimental near line 19 of /usr/share/snmp/mibs/UCD-DISKIO-MIB.txt
Cannot find module (SNMPv2-TC): At line 15 in /usr/share/snmp/mibs/LM-SENSORS-MIB.txt
Did not find 'DisplayString' in module #-1 (/usr/share/snmp/mibs/LM-SENSORS-MIB.txt)
Did not find 'ucdExperimental' in module UCD-SNMP-MIB (/usr/share/snmp/mibs/LM-SENSORS-MIB.txt)
Unlinked OID in LM-SENSORS-MIB: lmSensors ::= { ucdExperimental 16 }
Undefined identifier: ucdExperimental near line 32 of /usr/share/snmp/mibs/LM-SENSORS-MIB.txt
Cannot find module (HOST-RESOURCES-MIB): At line 0 in (none)
...


Sziasztok!

Segítsetek! Áramszünet következtében több fájlom, könyvtáram odalett. De sajnos egy könyvtáram is odalett, amit én balga nem toltam fel felhőbe... Így naná, hogy eltűnt,azaz inkább olvashatatlanak lettek. Sok kép lett oda, amik pótolhatatlanok.
Próbálkoztam az extundelete-vel, de az se segített.
Valaki adjon valami ötletet, hogy állítsam helyre különben a család megöl.
Szóval SOS.

Jelenleg eleg sokat szenvedunk az un. advanced format diszkekkel...
Ma reggel osszehasonlitaskepp kiszurtam egy furcsa hibat:


[root@fedorappc64 ~]# fdisk -l /dev/sds
Disk /dev/sds: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 65536 bytes


Szoval az fdisk azt mondja nekem, hogy a fizikai blokkmeret 4k...
Ez kicsit gyanus. Ugyanez a LUN atmappelve egy AIX hostra (7.1 TL3 SP1) a kovetkezot hazudja magarol :

# echo "scsidisk hdisk31" | kdb | grep block_size
uint cfg_block_size = 0x200;
uint block_size = 0x200;

Szoval az AIX csak 512 byte szektormeretunek latja ugyanazt a LUN-t.

Terjunk vissza a Linux-hoz.
Minden diszk informacio elerheto a /sys alatt is.
Esetunkben:

[root@fedorappc64 ~]# cat /sys/class/block/sdr/queue/physical_block_size
4096
[root@fedorappc64 ~]# cat /sys/class/block/sdr/queue/logical_block_size
512


Tehat a kernel szerint is a fizikai blokkmeret es a logikai blokkmeret megegyezik az fdisk altal reportaltal. Gondolom az fdisk innet veszi ezeket az informaciokat. (Nem volt meg idom vegigmenni az fdisk logikajan)

A harmadik lehetosegunk linuxon az sg3_utils csomag altal szallitott sginfo utility.
Itt nekunk az "Format Device mode page (0x3)" informaciora van szuksegunk ami igy nez ki erre a diszkre:


[root@fedorappc64 ~]# sginfo -f /dev/sds
Format Device mode page (0x3)
-----------------------------
Tracks per Zone 0
Alternate sectors per zone 0
Alternate tracks per zone 0
Alternate tracks per lu 0
Sectors per track 128
Data bytes per physical sector 512
Interleave 0
Track skew factor 0
Cylinder skew factor 0
Supports Soft Sectoring 1
Supports Hard Sectoring 1
Removable Medium 0
Surface 0


Linux eseten kinek lehet hinni?
A kernelnek ?
Az SG Informacionak ?
Az AIX altal mutatott blokkmeretnek ?

Lehetseges, hogy ez egy bug a Linux/AIX/NetApp SAN-ban ...

Viszont az sginfo es az AIX informacio szepen egybevag. Szoval arra hajlok, hogy az igazsag az 512 byte mint blokkmeret.

Sziasztok,
Lehetseges, hogy nagyon amator a kerdes. Most ismerkedem a tuzfalakkal, es be is allitottam magamnak egyet ami minden csomagot blokkol, csak olyan kommunikacio lehet, amit en engedelyezek. A szerver benn van egy router mogott, es az a problema hogy csak belso halozatbol erem el a szerverszolgaltatasokat /http, ssh/, amig a klienssel router mogott vagyok, abban a pillanatban, ha "kintrol szeretnek csatlakozni" a keresek el- time out olnak. A router en a port forward be van allitva tcp es udp portra egyarant. Rosszul hatarozom meg a rule okat?

Tuzfal
---
# Generated by iptables-save v1.4.21 on Fri Jan 29 18:11:32 2016
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:LOGGING - [0:0]
-A INPUT -p tcp -m tcp --dport 8531 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

-A INPUT -j LOGGING
-A OUTPUT -p tcp -m tcp --sport 8531 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: "
-A LOGGING -j DROP
COMMIT
# Completed on Fri Jan 29 18:11:32 2016

---

iptables -L kimenete
---
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:8531
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:https state NEW,ESTABLISHED
LOGGING all -- anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp spt:http state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:https state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:8531 state RELATED,ESTABLISHED
ACCEPT udp -- anywhere anywhere udp dpt:domain ctstate NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:domain ctstate NEW,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere tcp dpt:http

Chain LOGGING (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 2/min burst 5 LOG level warning prefix "IPTables-Dropped: "
DROP all -- anywhere anywhere

---

Van egy fájl a fájlrendszeren. Többféle verziója is használatos, és még boot előtt kellene a megfelelőt a helyére másolni, hogy boot során már a megfelelő verzió legyen a helyén, az addig ott levőt felülírva.
Van-e mód arra, hogy hogy ezt például GRUB-ból megtegyem, hogy egy adott menüpontot kiválasztva egy verziót másol a helyére, másikat választva meg másikat?
Vagy máshogy?

(Konkrétan az /etc/network/interfaces fájlról van szó: más hálózati környezetben más beállításokkal kellene bootolnia a gépnek, más interface-en át csatlakozni a default gw-hez.)

Köszönöm, ha okosat szólsz.

Tudna valaki ajánlani ipari vonalkód leolvasót, ami usb-s és Linux alól jól kiolvasható amit küld? Tehát felismeri a Linux :)

olyat szeretnek, h adott user minden bejovo cuccat cc-zze egymasik dobozra is. mint a transport, de kozben tartsa meg lokalban is. Hogyan csinaljam? Nem ilyenolyan trukk erdekel, h procmail meg ilyesmi, pusztan postfixbol kivanom ezt letudni. Otlet?

A zfs sharenfs érdekesen viselkedik, ha becsatolok egy subvolume-ot vmware esxi alá, és ebben a subvolume-ban további subvolumok vannak.
pl megosztom a zpool/vm subvolumeot, amiben még ott van a vm1, vm2 és vm3 subvolume is:
zpool/vm/vm1
zpool/vm/vm2
zpool/vm/vm3

Az egész zfs, stb egy ubuntu 14.04-en van.
Ha bemásolok bármit a /zpool/vm/vm1 mappába ubuntu alatt azt nem látom vmware felületén, és ha a vmware felületén másolok be valamit a vm1 mappába az pedig nem látszik a linux oldalán.
Ugyebár a zfs az alapból a teljes zfs fát rácsatolja egy könyvtárstruktúrára.
Arra rájöttem, hogy amennyiben ubuntu alatt másolok be bármit a vm1 mappába az a zfs-be kerül, de ha a vmware oldalról másolok be valamit akkor az abba a mappába kerül amire a vm1 rá van csatolva: /zpool/vm/vm1, tehát az én esetemben a / partíció ext4 fájlrendszerébe kerül.
Mi ennek az oka és hogy tudom kiküszöbölni.
Picit komplikált, ezért nincs sok ötletem, hogy tudnék neten rákeresni.

Ha a /zpool/vm megosztást egy másik linuxon csatolom fel akkor már látom benne amit helyileg belemásoltam, de ha egy másik vmware-en, akkor az első vmware-en bemásolt fájlokat látom.

Az megérteném ha NFS-be lenne egy kapcsoló ami a megosztás alá felmountolt dolgokat nem osztaná meg, de az számomra eléggé érdekes, hogy különböző helyre felcsatolva más-más tartom jelenik meg.

Megoldás:
A problémát az okozza, hogy a vmware alapból NFSv3-at használ a felcsatoláshoz. Az esxi 6.0 már tudja az NFSv4.1, ami már le tudja kezelni azt, ha egy csatolóponton belül további helyi fájlrendszerek is fel vannak csatolva.
Hogy működjön kényszeríteni kell az esxi-t, hogy NFSv4.1-et használjon:
esxcfg-nas -a -o 10.10.65.12 -s /zroot/template -v 4.1 valami

Fejleszti még valaki a Griffith nevű filmkatalogizáló alkalmazást?
A bugtracker tele van több éves bejegyzésekkel, amikkel nemigen törődik senki.

Sziasztok.

Egy szerverre van irányítva több domainem is. A szerverre beállítottam a Dkim-et, amit ha check-auth@verifier.port25.com címre küldött levéllel tesztelek tökéletes eredményt kapok:
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham

Ha gmailra küldöm ugyanilyen levelet a gmail a fejlécben ezt adja vissza:
dkim=neutral (bad version)

Eddig még megérteném, biztos valamit én nem állítok be jól, de tegnap kiderült, hogy valami más gubanc lehet, mivel van olyan e-mail cím amiről ha küldöm Bad versiont kapok, de ugyanazon domain másik e-mailjét pedig elfogadja: dkim=pass

A rendszer ISPConfiggal van telepítve, de kézzel lett OpenDkim feltolva rá, és beállítva.
A levelek fejlécébe az aláírás be is kerül, a DNS vizsgálatoknál mindent okénak mutat akárhol ellenőrzöm.

Elég régóta szívok ezzel a problémával nagyon örülnék ha valaki tudna érdemben segíteni, mert, most hogy már azt látom ugyanazon a domainnél más fiókkal is problémázik, miközben teljesen véletlenszerű fiókok meg jók nem tudom hol keressem a hibát.

Segítséget előre is köszi.