2. Megint atnevezte a NIC-eket ... ez volt a masodik amikor megtette
Az elso akkor volt amikor ens192/ens224-rol nevezte at eno16780032/eno33559296-re egy Vmware virtual hardware 8->10 frissites utan.
Most pedig csak a 7.3 frissites tortent es visszanevezte ens nevekre.
Mivel relative meguntam az allando varialast megkapta a net.ifnames=0 opciot. Sosem zavart az eth* ellenben a 11-12 karakter hosszu eno annal inkabb ...
3. Egyetlen debug csomag sincs telepitve. Ennek ellenere a 7.3 frissites utan ugy dontott a grub2-mkconfig, hogy jo otlet midnen egyes kernelhez a "with debug" opciot legeneralni es a default boot kernel-t is ilyenne tenni ...
A megoldas:
/etc/sysconfig/kernel
MAKEDEBUG=no
grub2-mkconfig
4. Eltuntek a particio delimiterek (p):
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpatha -> ../dm-0
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpatha1 -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpatha2 -> ../dm-2
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpathac -> ../dm-9
lrwxrwxrwx 1 root root 8 Mar 23 11:31 mpathac1 -> ../dm-12
lrwxrwxrwx 1 root root 8 Mar 23 11:31 mpathac2 -> ../dm-13
Szerencsere ez csak a /boot particio mountolasaban es mas service-ek mukodeseben okozott gondot amik mpathacp1-kent hivatkoznak a particiora...
Egy gyors modositas a "/lib/udev/rules.d/62-multipath.rules" fajlban es reboot utan ez is megoldva...
5. Meg varom, hogy mi mast kell visszaallitanom a frissites elotti allapotra ...
- hajduarpad blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
A 2esben az a szép, hogy épp az volt az indoklás ezekhez a hányadék nevekhez, hogy ez majd jól stabilan úgy marad, bármit mahinálsz is.
- A hozzászóláshoz be kell jelentkezni
A mahinálást bírja is, csak az a fránya frissítés ugye. Merhogy az nehezen tesztelhető a sok hülye felhasználó sok hülye környezete miatt. bezzeg a rencergarázdáknak mind egyre jár az agya. (Pizza, sör, dudák)
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
ja értem, akkor ez olyan mint a java platformfüggősége, hogy egy viszonylag jól definiálható, és változásoktól inkább mentes architektúrális függést cseréltünk egy mozgó softwareplatformtól való függésre. Jippi.
- A hozzászóláshoz be kell jelentkezni
Azért ha a hardvert "lecseréled"/frissíted alatta, akkor akár még érthető is, hogy változni fog az OS-ben látszó hw-es azonosító...
- A hozzászóláshoz be kell jelentkezni
Kiemelem neked a lényeget: "Most pedig csak a 7.3 frissites tortent es visszanevezte ens nevekre."
Szóval az elsőben igaza volt (amikor új VM lett alatta), de ebben a mostaniban azért nem biztos.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, nekem ilyet nem csinált CentOS, de majd megkukkolom...
- A hozzászóláshoz be kell jelentkezni
Az elso alkalommal amikor atnevezte a NIC-eket csak VM update volt ... ami azert nem kene ilyet okozzon szvsz... De hat VMware meg virtualizacio meg Linux ...
Majd kivancsisagbol megnezem pontosan mi valtozik a vmx-ben (es OS oldalon) ha a hardware-t updatelem ... most mar kivancsi lettem :)
- A hozzászóláshoz be kell jelentkezni
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInt…
Come again, what good does this do?
With this new scheme you now get:
Stable interface names across reboots
Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place (to the level the firmware permits this)
Stable interface names when kernels or drivers are updated/changed
Stable interface names even if you have to replace broken ethernet cards by new ones
The names are automatically determined without user configuration, they just work
The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called
Fully stateless operation, changing the hardware configuration will not result in changes in /etc
Compatibility with read-only root
The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks
Applicability to both x86 and non-x86 machines
The same on all distributions that adopted systemd/udev
It's easy to opt out of the scheme (see below)
szóval ja, az ígéret az volt, hogy nem nagyon. Nyilván, ha a vm update valamit nagyon alátúrt, akkor fog változni, de igazából az derül ki, hogy előrébb in practice nem lettünk, de legalább rondák a nevek :)
- A hozzászóláshoz be kell jelentkezni
Idézet ugyanonnan:
The following different naming schemes for network interfaces are now supported by udev natively:
1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5. Classic, unpredictable kernel-native ethX naming (example: eth0)
Szerintem annyi történt, hogy a virt. hardver frissítése után az elnevezés valamiért a negyedik séma alapján generálódott.
- A hozzászóláshoz be kell jelentkezni
na jó, de ilyennek pont nem nagyon kéne történni.
- A hozzászóláshoz be kell jelentkezni
Nekem nem történt ilyen, pedig volt virtual hardware frissítés - igaz, az CentOS vala, ha jól emlékszem, de ilyen szempontból ennek mindegynek kéne lenni - gyanítom, hogy a kolléga esetében valami más is történhetett.
- A hozzászóláshoz be kell jelentkezni
azért ez elég worksforme-re sikeredett :)
- A hozzászóláshoz be kell jelentkezni
A lenyeg, hogy semmivel sem konnyitette meg az eletet az uj sema ...
Szamomra az eno/ens/enp/enx nevek inkabb unpredictable mint az ethX ami megjosolhatoan eth es egy szam.
Remelem egy nap eljut oda a Linux is, hogy vegre a developerek megertik ha minden egy verzioval feltalaljak a spanyolviaszt azzal nem jutnak elorebb. Vasokol kene es teljesen szabalyozott keretek a fejlesztoknel. Legalabb a a magukat enterprise-nak mondott OS eseten... Bar a Linuxnak annyi koze van az enterprise-hoz mint rokanak a repuleshez ...
- A hozzászóláshoz be kell jelentkezni
Miről upgrade-eltél mire?
- A hozzászóláshoz be kell jelentkezni
Nem volt nagy ugras: RHEL 7.1 base -> 7.3 base
- A hozzászóláshoz be kell jelentkezni
Gondolom nem vigasztal, de sok minor release upgrade-et csináltam, és szinte mind problémamentesen lezajlott.
Igazából engem csak az zavar, hogy nem törli le a régi kerneleket, és ha kicsi a /boot, az egy idő után betelik.
- A hozzászóláshoz be kell jelentkezni
>Megint atnevezte a NIC-eket
2.4 megint not affected
- A hozzászóláshoz be kell jelentkezni