CentOS 7: hálózati beállítások és újdonságok, amik miatt nem találom a régi funkciókat és szolgáltatásokat

UNIX kezdő

Sziasztok!

Használ valaki CentOS 7-et?

A CentOS 5 és 6.5-höz képest teljesen máshogy vannak a dolgok, de biztos az én rutintalanságom miatt is lehet ez.
Példák:
- felrakom a MySQL-t, és nem kerül be az /etc/init.d/mysql -be egy indító/leállító/újraindító script, stb
- A hálózat újraindítása is változott, ezt így kell újraindítani:

systemctl restart network.service

Nem azért, de ezt beírni jóval lassabb, mint az init.d-s változatát.

Aztán ott a nmtui parancs, amivel szépen terminálos gui-ban lehet állítani a dolgokat.
Hálózati maszkot csak /24 módszerrel lehet beírni. Megint csak az én hülyeségem lehet, én szeretem beírni a 255.255.255.0 -t.

Ott vannak a /etc/sysconfig/network.scripts mappa tartalma:
itt már nem eth0 és eth1 van a hálózati kártyákhoz, hanem egy 7-8 karakteres más név, ráadásul a
ifcfg-eovkrof1 -ben sem a megszokott dolgok vannak
HWADDR helyett HWADDR1, IPADDR helyett IPADDR1, nincs NETMASK és van NAME, stb, stb...

Újraindításhoz:

systemctl restart network.service

Ami külön szépség, ha megpróbálom bekapcsolni az eth1-et, amivel 2 gépet akarok összekötni külön subneten, nem működik valamiért, és akkor az egész hálózat nem működik.
Tehát ha eth0-n vagyok a switch-en, és a notebook-omon át kapcsolódom ssh-n, majd átírom az eth1-et bármire, ha az eth1 nem megy, az eth0 sem fog menni, hiába semmi köze hozzá.
Tehát marad, hogy rádugni a szerverre billentyűt és monitort, és helyre hozni ezt a hibát.
Hamarosan megnézem, hogy mi az oka, hogy nem megy az eth1, csak furcsa, hogy mindkét gépen ugyanazt csinálva nem megy, és mindkét gépen jó az eth0.

Megírom a hibaüzenetet.

Nem tudtam simán csak az eth1-et újraindítani, ifdown, ifup nem kezelte... :-( Ilyen még nem fordult elő, minden Linux-on eddig megtaláltam...

Kérdéseim:
- Miért nem rak a CentOS 7 az init.d mappába szolgáltatásokhoz kapcsolódó script-eket?
- Van aki szerint jobb a CentOS 7 hálózat és IP kezelésének beállításai?
- Az normális, ha nem megy az eth1, de az eth0 igen, akkor network restart-nál az eth0 sem fog működni az eth1 hibája miatt? Ha kikapcsolom az eth1-et, akkor meg jó lesz az eth0?

Fő kérdés: hol nézzek utána ezeknek, hogy tudjam?

UPDATE1:

Szuper, sikerült belefutnom ebbe:
NetworkManager crashes when setting hostname and SELinux is disabled

https://bugzilla.redhat.com/show_bug.cgi?id=1122826

  • 10258 megtekintés

( zeller | 2014. 09. 16., k – 10:22 )

Üdvözöllek a "hogy hívják ma a print parancsot" avagy "tanuljunk újra mindent, mert az cool" világában.
A sysvinit-et kihajítani nem kell félnetek jó lesz... Persze, meg lehet tanulni, meg hozzá lehet szokni, de hogy nagyon sok olyan UNIX-os ember, aki már akkor is UNIXozott, amikor a systemd fejlesztői még csak tervben voltak, nos... Szívni fogunk.

Bár én pár fokkal nagyobb porszem vagyok, mint az IPV6-ban egy IP... Nyilván nem számít a szavam, de nem értem, hogy miért kell a jól megszokott init.d -s dolgokat máshogy csinálni, főleg egy CentOS-ben. CentOS 6-ig elmondhattam, hogy tudtam pár dolgot, hogy mit hogy kell... már EZT SEM mondhatom el... Szuper... Ha jön a CentOS 8, félve fogom kiadni az ls és cp parancsokat... izgulni fogok, hogy lesz-e /boot/ /etc/ /var/ vagy /usr/ ... de főként, hogy mik lesznek benne...

Értem én a viccet, csak ebből a szempontból nem szeretem...

A Microsoft mikor megcsinálta talán az Office 2007 zseniális új felületét, amikor mindent máshova rakott a Word-ben és Excel-ben egy új elgondolás alapján, valamint a hagyományos menü helyett feltalálta, hogy a Windows 95 Start menüjét mint Excel menü fogja használni, azt nem szerette senki a környezetemben. Több füge 3rd party cég kiadott pénzért (!) egy olyan felületet, amivel az Office 2007-en Office 2003 és előbbi módon lehetett megtalálni az ikonokat, funkciókat, csak hogy lehessen használni egy átlag felhasználónak. Aztán úgy tudom, a Microsoft is kiadta ezt a megoldást később ingyen, ami sok mindent megválaszol...

Ezzel azt akartam felvezetni, hogy lesz-e a Centos 7-hez is valami OldCentOSFeelingCompatibilityPackForDummiesForCentos-7.x86_64.rpm ?
Ami megoldja, hogy a network script-ek és az init.d például úgy legyen ahogy régebben? ^^

Tudom, hogy utópisztikus volt, és biztosan 2038-ból visszatekintve nevetséges és kőkorszaki megoldás az init.d és a network scripts, de akkor is... :-)

Sakk-matt,
KaTT :)

A jó pap is holtáig tanul, tartja a mondás. Az IT különösen ilyen. Egyre több "IT" -tól is hallani olvasni, hogy minek meg miért meg már megint új, lehet tanulni stb. Nos akinek ehhez nem sok kedve van szerintem válasszon olyan szakmát ami lassabban, vagy egyáltalán nem fejlődik és akkor a megszerzett tudást használhatja élete végéig. Szoktam is mondani, hogy menjen kapálni, azt most is úgy kell ahogy anno nagyanyáink csinálták.

Fedora 20, Thinkpad x220

OFFTOPIC

Igazad van, megyek is kapálni... :-)
Folyamatosan képzem magam, de ha számomra nem logikus változás jön (például PHP-ban egy régi, létező funkció más visszatérési értéket vesz fel az új PHP változatban, mint előtte...), akkor kicsit pörgök, aztán túllépek rajta.

/OFFTOPIC

Sakk-matt,
KaTT :)

őszintén mi az amire tényleg szügséged volt? újraindítja a process-t ha az elhalt? annak Linuxon oka van h miért halt el. próbáld ez eljátszani inconsistens DB-nél és meglátod mit kapsz.
szerintem a systemd csak a fejlesztőknek jó. oké h könnyebben lehet a processeket menedzselni de arra nem a 'start' (régebbi nevén init) kellene újraírni.

valamint, az init tette a dolgát. nem volt vele gond. miért kellett kidobni? miért????????????????????
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Tette a dolgát (úgy 40 éve már...), de nem kezelte a szolgáltatások függőségét (logikus kiegészítéssel megoldható), és nem tudta párhuzamosan indítani azokat. Mondjuk ez utóbbi elsősorban desktop-on gond, mert szervernél, ahol mostanság a vas is hosszú percekig szedi össze magát, mire hajlandó egyáltalán az OS betöltéséhez kezdeni, ott jóval kevésbé számít, hogy 5, 10 vagy több perc telik el a bootloader indulása és a rendszer üzemszerű állapota között.

azert ez gyenge erv. irni egy wrapper scriptet a script fuggosegekhez nem nagy cucc es meg a frissitesek sem fogjak hazavagni.
egyebkent valoban lassan allnak fel a vasak de virtualis kornyezetben nagyon gyors. pl vmware
nekem kb 15s az indulasi ido.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Ez szép és jó, csak nem skálázódik: ha két szolgáltatásod közt van egyirányú függőség, akkor oké: indítsuk el A-t, aztán B-t. Ha kétszáz szolgáltatásod közt van mondjuk csak 50 függőség, akkor már a "jó sakkozást" kategóriánál állunk.
Aztán bejönnek az ilyenek, hogy egy szolgáltatás függ attól, hogy egy fájlrendszer fel van-e csatolva (pl. nfs-en megosztott webroot apache alá). Ez systemd-vel egy dependency; init scriptből?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ilyen környezetben, ha jól csinálják, specifikus feladatokra vannak a VM-ek - a VM elindulása a boot (GRUB) kezdetéig, a virtuális hw inicializálása (kernel) viszi el az idő jelentős részét, nem annak a néhány tényleg fontos szolgáltatásnak az elindítása. (Ha 100-as vagy 1000-es nagyságrendben vannak olyan gépek, amik darabonként 20-30-50-sok szolgáltatást futtatnak, akkor ott a rendszer struktúrájával nagy bajok vannak szerintem.) Persze, a fölösleges szolgáltatásokat "illik" a production-be menés előtt kigyomlálni a gépekről.

újraindítja a process-t ha az elhalt?

Egy default off (ajánlottan meg on-failure) feature-t killernek beállítani legalábbis azt mutatja, hogy nem nagyon néztél utána.

Amire tényleg szükség volt?
1) Konzisztens és üzembiztos állapotlekérdezés (nagyon jó móka /disztib figyelni, hogy melyik démon hol tartja a pid fájlját [bizonytalan, hogy törli-e], milyen executable néven fut [pgrep és tsai-hoz], a függő szolgáltatások elindultak-e már stb.), a processzek figyelése
2) Konzisztens és rendszer-szinten kikényszerített erőforrás-limitelés
Szerk.: 2.5, mert ide illik) Konzisztens és rendszer-szinten kikényszerített biztonsági rendszerek (chroot, saját network, tmp stb.)
3) Krossz-disztró tool-rendszer (igen, valszeg ha elég hosszú életű lesz a systemd, az is annyira szét lesz barmolva, mint a SysV, egyelőre még nincs), akár olyan triviális dolgokig, mint hogy a hostnevet meghatározd.
...

nem volt vele gond.

Ha valóban nem volt vele gond, akkor miért van annyi helyettesítője, mint égen a csillag (openrc, upstart, systemd, ...) és több projekt, ami elvégez helyette feladatokat, cserébe kiveszi a kezéből a szolgáltatás kezelését (pl.: monit - aktív monitorozás, cserébe az üzembiztos működéshez az init helyett a monit kell, hogy indítsa a szolgáltatásokat) stb.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

valasz
1) - a fuggosekeg inditasa fentebb, a pid-fajlok torlesere valoban gondot okozhat, bar a normalis script megcsinalta. nem tudom h a systemd mitcsinal akkor ha veglegesen ledoglik egy process. meg nem teszteltem.
2) ismetelten - virtualis kornyezetben ez nem gond, fizikai szinten mert szinten jol kell beallitani a scriptet (ez systemd-nel is igy van szerintem, vagy eroforras kezelest is csinal?) valamint kell egy jo monitoring rendszer
3) ezt most nem ertem. mar most a systemd-vel allitod a host nevet

ahogy korabban is irtam, h ha egy szolgaltatas random vagy fix idonkent leall annak oka van es ki kell deritteni az okat. ilyet en csak windowsnal lattam ja lerohad a webservice, sebaj majd ujraindul....
no comment.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Továbbra is: EGY sor a service konfigjában, hogy mit kezdjen vele a systemd, ha lehalna. A Fedora-s javaslat az, hogy ha csak nincs nyomós érv (pl. hogy gondot okozhat az automatikus újraindítás) ellene, ez minden szolgáltatásnál legyen on-failure (hogy mi számít failure-nek, az a service típusától függ, man systemd.unit), a default a ne csináljon semmit.

nem tudom h a systemd mitcsinal akkor ha veglegesen ledoglik egy process.

A szolgáltatás típusától is függ, de többnyire: amint a szolgáltatáshoz tartozó cgroup kiürül (ez alól ugye nincs menekvés, ezzel mindig lehet követni őket), akkor hallottnak tekinti a szolgáltatást (és itt jön képbe a Restart opció értéke...)

virtualis kornyezetben ez nem gond

Virtuális környezetben már nem kell az erőforrásokkal/biztonsággal játszani? Megyek is virtualizálni... Az erőforrás-kezelés itt a rendszeren belül érvényes, vagyis hogy tudd szabályozni, hogy melyik process mit művelhet, mennyi memóriát és cpu-t vihet el - aminek virtuális környezetben is van értelme, mert virtuális környezetben is lehetnek egy-egy szolgáltatást érintő kiugró tüskék, ami közben a többinek is működnie kell. man systemd.resource-control

ezt most nem ertem. mar most a systemd-vel allitod a host nevet

Ez gondolom a szétbarmolt init-re vonatkozott: igen, disztrónként szét van barmolva. Nincs két ugyanolyan init script a disztrók között (pedig 95%-ban ugyanazokat a csomagokat szállítják...), emiatt pedig az összes beállító rendszer (amivel mondjuk egy Bind-ot chroot-ba zársz [RHEL: /etc/sysconfig/named ROOTDIR változója, Debian: /etc/default/bind9 az OPTIONS-ben meg tudsz adni új paramétereket a bind-nak, aztán a manból kikeresheted, hogy melyik a chroot]) disztó-specifikus lett. Egyelőre a systemd-nél ez nincs meg.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

koszonom ez a cgroup-s dolgot nem tudtam. utana olvasok ha lesz idom.

a virtualizalasnal arra gondoltam h 1 service 1 gep. es akkor a gepet korlatozod ugy ahogy kell.
szerintem N szolgaltatas 1 gep nem jo megkozelites pont az altalad sorolt okok miatt.

szetbarmotl init
igen, valoban igazad van. de naivsag azt gondolni h az ido elorehaladtaval a nagyobb distrok nem fogjak maguknak testreszabni a beallitasokat. ez csak akkor kerulheti el a systemd h a fejlesztok majd (tesznek rola) h csak is egyfelekeppen egy helyrol lehessen testreszabni.

--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

A szolgáltatás alatt én mondjuk most nem kifejezetten mondjuk a ldap-ot értettem, hanem az összes systemd szolgáltatást. Ill. mondjuk egy Samba4+Bind9 kombó kívülre egy szolgáltatásnak tűnik, de két, egymástól kölcsönös függő service lesz (a Bind mondjuk fut a Samba4 nélkül is, csak a fájljai kellenek :) ).
De pl. egy időzített feladat (akár úgy, hogy fut egy cron service, akár natív systemd időzített szolgáltatás), teszem azt egy backup, is külön szolgáltatás, és annál is hasznos, ha egy-egy sorral tudod korlátozni, hogy akkor IO-ból, CPU-ból és RAM-ból mennyit vihet :) [he, azt hittem csak erőltetettebb példa fog eszembe jutni :) ]

--

Abban, hogy ha elég sokáig él a systemd, akkor a disztribkészítők mind a saját ízlésükre fogják szabni egyet értünk :) Viszont ha a leggyakoribb 80% egységesedik, már előrébb leszünk.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

pl. itt http://schnouki.net/posts/2013/12/19/resource-control-with-systemd/ (ebből látszik, hogy minden unit fájlra működik a korlátozás, mondjuk feltételezi, hogy default be van kapcsolva a MemoryAccounting és CPUAccounting [BlockIOAccounting-ot ugye nem csinál], a slice szinten érdemes explicit bekapcsolni, bár a limit-ek implikálják)
Az elv ugyanez, mondjuk a unit fájlokban levő include helyett a drop-int ajánlott használni (/etc/systemd/system/[unit].[típus].[d]/[szám]-akármi.conf), a kódban már szerepel, hogy valamikor ki fogják venni az include-ot. A systemd-nél mindig érdemes az adott gépen levő man-t olvasni, a neten levő systemd.resource-control-ban pl. szerepel a CPUQuota, BlockIO[Read/Write]Bandwidth stb., ami a 213-ban jelent meg, előtte CPU-t és IO-t csak arányokkal lehetett állítani, azóta fixen is.

Régi, már valszeg nem aktuális leírás a systemd for administrators sorozatból: http://0pointer.de/blog/projects/resources.html

(resource limit címszó alatt én annó azzal játszottam, hogy a belépő userek memória-foglalását korlátozzam, ami annyiból speciális, hogy azok mindig egy user-UID nevű slice-ot kapnak. Egy egy pár soros bash script (systemctl set-property hívogatás) megoldja)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

egy kerdes, te vegigolvastad a systemd dokumentaciot? ez az eroforras management jol hangzik bar fellabu kacsa disk I/O nelkul.

na a kozeljovoben jobban atolvasom ezeket a slice-t mert nem vilagos. esetleg majd zargatlak kerdessel ha nem baj.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

A systemd for administrator egy nagyon jó kiindulási alap, a man page-i meg majdhogynem logikusan vannak felépítve (a vonatkozó direktívák a systemd.[unit típus], a közösek pedig a systemd.unit, systemd.resource-control stb.-be, témánként). Van disk I/O, csak nem abszolút korlátokkal, hanem arányokkal (meg ha jól emlékszem csak CFQ io ütemezővel megy az arányos játék, a sávszél limitet más szinten csintálták meg - a man-ban hivatkozott blkio-controller.txt-ben le van írva [ez cgroup szinten dokumentálja ezeket a feature-öket, nem systemd szinten])

A slice gyakorlatilag csak egy gyűjtő valamilyen okból összetartozó (alapból: rendszer unit / felhasználó unit, utóbbiak loginonként külön slice-ban) unit-oknak.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( blackluck v | 2014. 09. 16., k – 10:30 )

Hello!

"felrakom a MySQL-t, és nem kerül be az /etc/init.d/mysql -be egy indító/leállító/újraindító script, stb"
Systemd-t hasznal mar 7-es centos(rhel), jopar dologhoz megirtak a systemd konfigot, de tudja hasznalni regi init.d-s scripteket is, systemctl status network

"systemctl restart network.service
Nem azért, de ezt beírni jóval lassabb, mint az init.d-s változatát."
Onmagaban ennyit nezve tovabb tart beirni, de ha megszokod systemctl egyeb funkcioit (status , enable/disable, sima systemctl parancs stb.) akkor mar egyszerubb lesz mert 1 parancs alatt probalod keresni ezeket.

"Ott vannak a /etc/sysconfig/network.scripts mappa tartalma:
itt már nem eth0 és eth1 van a hálózati kártyákhoz, hanem egy 7-8 karakteres más név, ráadásul a
ifcfg-eovkrof1 -ben sem a megszokott dolgok vannak
HWADDR helyett HWADDR1, IPADDR helyett IPADDR1, nincs NETMASK és van NAME, stb, stb..."
Atirhatod a megszokott elnevezesekre, azokat a network manager adja nevnek, talan udev alapjan, de modosithatod nmtui-bol is vagy siman kezzel is lehet szerkeszteni megszokott modon ifcg- es tarsai file-okat.
Extrakent belekerultek valoban olyan dolgok, de attol hogy alapbol nincs benne NETMASK nem jelenti hogy ne kezelne es NAME volt korabban is.
Amugy fejlodott nmtui abban hogy mindenfele bonding, vlan stb dolgot be tudsz allitani vele amit hasznosnak tartok.

"Az normális, ha nem megy az eth1, de az eth0 igen, akkor network restart-nál az eth0 sem fog működni az eth1 hibája miatt? Ha kikapcsolom az eth1-et, akkor meg jó lesz az eth0?"
Szerintem ott valami osszeutkozhetett, nalam mukodik rendben a network restart.

"Fő kérdés: hol nézzek utána ezeknek, hogy tudjam?"
https://access.redhat.com/sites/default/files/pages/attachments/rhel_wh…
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…

( SzBlackY | 2014. 09. 16., k – 10:41 )

- felrakom a MySQL-t, és nem kerül be az /etc/init.d/mysql -be egy indító/leállító/újraindító script, stb

Van helyette systemctl enable mysql.service, ami cross-platform működik a systemd-alapú rendszereken (még ha adott gépen a MySQL init scripttel is van hívva), nem úgy, mint a chkconfig, insserv stb. Jah, meg systemctl start mysql.service. Ja, és már a 6-osban is "illett" az init scriptek közvetlen hívogatása helyett a service-t használni.

itt már nem eth0 és eth1 van a hálózati kártyákhoz, hanem egy 7-8 karakteres más név

Ami minden újraindítás után konzisztens lesz (sőt, ha teletöltöd USB-s hálózati eszközökkel, akkor is). Sőt, rendszerek közt is konzisztens lesz (ha jól rémlik az összes elnevezési konvenció, ami alapján elnevezget). Amúgy kikapcsolható, visszakaphatod a régi eth0/eth1 neveket, lásd: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInte…

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Köszönöm az infókat!

" Ja, és már a 6-osban is "illett" az init scriptek közvetlen hívogatása helyett a service-t használni."

Hát én voltam akkora tapló, hogy az init.d-s scripteket használtam.
Így utólag is elnézést kérek mindenkitől, akit érint. Szégyellem magam.

Mentségemre szolgáljon, hogy CentOS 5.x-ről lett frissítve a CentOS 6-ra, de azért szánom-bánom a bűnöm.
Ez nem mentesít a ténytől.

Sakk-matt,
KaTT :)

Nem akarok gonosz lenni, de RHEL/CentOS 5-ben is már ott volt a /sbin/service :) [pl.: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-start.h…, http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-samba-start…, http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-dhcp-config… stb. - egyébként tényleg csak egy sima wrapper az init scriptek körül, de biztonságosabb azon keresztül indítani őket, mert egy állandó környezet állít be; erre vonatkozott az "illett", nem sértés akart lenni]

Ráadásul a service/chkconfig/... "forward-kompatibilis" maradt a systemd-vel (mert a scriptek tele vannak a hívásaikkal), a systemd-natív szolgáltatásoknál egyszerűen a megfelelő systemctl parancsot futtatja (kiírja, hogy redirecting) - és fordítva is, ha SysV service-re hívod a systemctl-t, az átirányítja a megfelelő parancsra: 


> cat /etc/redhat-release 
CentOS Linux release 7.0.1406 (Core)
> service httpd start
Redirecting to /bin/systemctl start  httpd.service
> ls /etc/init.d
functions  iprdump  iprinit  iprupdate  netconsole  network  README
> systemctl disable iprupdate
iprupdate.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig iprupdate off

---

Szerk.: http://www.freedesktop.org/wiki/Software/systemd/ <- ezen az oldalon linkelve van a Systemd for Administrators cikksorozat, érdemes egyszer átolvasni, szépen rávilágít a miértekre és hogyanokra, és - azzal együtt is, hogy eléggé gyors ütemben fejlődik és módosul a systemd - a benne rejlő lehetőségekre.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem voltál gonosz, a saját hiányosságaimat figuráztam ki - legalábbis ezt akartam elérni... :)

Köszi a linket, el fogom olvasni.
Már nagyon berögzült a tab gombbal gyorsított /etc/init.d/ és az utána lévő pár szolgáltatás beírása (vajon csak nekem?!), ezért is sajnálom az újat.

Sakk-matt,
KaTT :)

( locsemege v | 2014. 09. 17., sze – 00:58 )

Ha rendszeresen adminisztrálsz CentOS-t, RHEL-t, Scientific Linuxot, akkor hobbiból, desktopon használj Fedorát, így mire a Fedorából RHEL lesz, már a kisujjadban lesz az új technológia. Systemd Fedorában ha jól emlékszem, Fedora 15 óta van, annak bizony már 3.5 éve.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm, jogos, csak amikor még pár éve Fedora volt a desktop, sok szívás volt az ATI driverrel, és visszatértem a Windows-ra, aztán ott maradtam...
Kijött egy Fedora upgrade, felraktam lelkesen és elszállt a grafikus felületem. Majd olvastam, hogy valami bug volt, sorry...

Sakk-matt,
KaTT :)

Ha jól értelek, szoktál CentOS-t adminisztrálni. Akkor, ha desktop-on egy frissítés miatt elmúlik a grafikus felületed, miért a Windows telepítés a reakciód ahelyett, hogy megcsináltad volna? Ritkán van vele gondom, de ha mégis, nem szoktam egykönnyen feladni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( chx | 2014. 09. 17., sze – 10:49 )

up (ubuntu -> centos váltást tervezek)

____________________
echo crash > /dev/kmem

( gergelykiss | 2014. 09. 17., sze – 11:28 )

Kérdéseidre a válaszok:

- Nyilván azért, mert a systemd miatt már nincs erre szükség. Amit ott hagytak, azt bizonyára csak a kompatibilitás végett hagyták ott.
- Nem érzek lényegi különbséget ezen a téren a CentOS 6-hoz képest, az egyetlen feltűnő változás az interfészek átnevezése volt (eth0 -> enp7s0). Biztos emögött is van valami logika, csak én nem vagyok elég tájékozott. :)
- Biztosan nem normális ez a viselkedés, bár nem teljesen értem, mit jelent a "jó" és a "nem megy" jelen esetben. Ha hibás a konfig, akkor azt javítani kell, nincs mese, ha ezen elhasal a szkript, és emiatt nem állnak fel az interfészek, az talán nem olyan súlyos hiba. Ha viszont egy interfész átmeneti leállása miatt nem áll fel a többi interfész, az már erősen bug-gyanús.

Egyébként már több mint egy éve CentOS felhasználó vagyok, és egyáltalán nem bántam meg a váltást.

Otthon és munkahelyen is CentOS 7 fut a gépemen, amint megjelent a stabil release, frissítettem (először csak otthon, később munkahelyen is). A kezdeti problémák, újítások és változások megoldása, illetve elfogadása után sikerült ismét úgy felépítenem a desktop környezetemet, hogy gyorsan, kényelmesen, különösebb nehézségek nélkül tudjak dolgozni, és ez nem igényelt komolyabb erőfeszítést. Elolvastam a release notes-ot, néhány releváns man page-et, neten pár idevágó cikket, és megbékéltem a helyzettel. :)

A sysvinit vs. systemd problémakör egyébként egyáltalán nem a CentOS sajátja, a Debian is átállt systemd-re a wheezy-ben, ott is volt ellenszél bőven, a legmarkánsabb kikelésről trey is megemlékezett nemrégiben.

Hogy egy-egy ilyen változtatás jó-e vagy sem, az szerintem mindig csak késleltetve derül ki. A felhasználók/adminok megismerkednek vele, aztán vagy visszasírják a régi megoldást, vagy szép lassan megtanulják és elfogadják, hogy már más szelek fújnak. Ahogy mások is írták előttem, az IT bizony ilyen szakma, más szakmákhoz képest sokkal gyorsabban és dinamikusabban változik, ezzel sajnos együtt kell élni. Ezt jól szemlélteti, hogy annak a sysadmin-nak törik fel legelőször a szerverét, aki képtelen haladni a korral, nem veszi figyelembe az új veszélyforrásokat, és nem fejleszti a védelmi vonalait.

Persze lehet, sőt kell is vitatkozni azon, hogy kellenek-e ezek az újítások, de ezzel együtt tudomásul kell venni, hogy olykor megváltozik néhány jól megszokott, berögzült mechanizmus. Én a magam részéről nem igazán tudok állást foglalni a kérdésben, de ha a nagy RedHat is jónak látja a systemd használatát, hát áldásom rá, hajlandó vagyok azt a néhány új parancsot megtanulni, amivel kiváltották a jó öreg "/etc/init.d/service restart|reload|start|stop|..." parancsokat.

Az utánanézés első lépése szerintem mindig az legyen, hogy elolvasod a release notes-ot, abban általában szépen kiemelik a lényegesebb változásokat. Ha mégsem, akkor ott a dokumentáció, amit, ha jól látom, a 7-es verzió óta már csak szimplán linkelnek a RHEL-től:

http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7#head-4d1bf7a5a41f87…

a Debian is átállt systemd-re a wheezy-ben, ott is volt ellenszél bőven

A Jessie-ben fog csak átállni.

Biztos emögött is van valami logika,

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInte…

Persze lehet, sőt kell is vitatkozni azon, hogy kellenek-e ezek az újítások,

Szerintem az újítás szükségességén nem lenne szabad vitatkozni, max. az implementáción lehetne.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

tokeletesen egyetertek veled. az ujitass szukseges, de a mikentje.

ethN nevek torlese - miert jo ez nekik? csak szivatjak az embert, siman lehetne a HW cim szerint sorbarendezni a halokartyakat es nem ilyen buta neveked adi nekik mint: wlp3s0 vagy m1. Nem tudom nekem soha de soha nem fordult elo velem h mas kartya nevet kapott a NIC mint amit beallitottam.
hostname - miert akar egy process manager hostnevet allitani
journald - miert kell a systemd-nek eroszakosan loggolni (ha kikapcsolod akkor nincs logging egyaltalan meg az rsyslog sem kap semmit)

valamint a fejleszto kozosseg mentalitasa!
gyakori valaszok:
WONTFIX, by design, vagy egyszeruen ignoralnak, rosszabb esetben ugy nyilatkoznak h amit ok csinalnak az a tuti es ok jobban tudja h NEKED mire van szukseged az uzemelteteshez.

itt egy jo kis(hosszu) leiras arrol h mit akarnak
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.h…

mindenki dontse el maga. szerintem ez elmebaj.

--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

ethN nevek torlese - miert jo ez nekik? ... lehetne a HW cim szerint sorbarendezni a halokartyakat

Tudom, hogy a három bűvös szám, de már kétszer linkeltem ebben a topikban a miértet - ami oldal alján ott van, hogy egy egyszerű symlinkkel hogy lehet kikapcsolni. Egyébként (linkelt oldal) 1-3 szabály pont ez, hogy a kártya fizikai elhelyezkedése szerint kapja a nevét.

hostname

Mert ki más? A disztribúciókban volt megoldás erre - minden disztribben más. Egy faék szolgáltatás, cserébe a systemd rendszereken nagy valószínűséggel elérhető és az alkalmazások tudják használni. Egyébként nem a process manager végzi, hanem a systemd-hostnamed, ami a systemd ernyő-projekt része.

journald - miert kell a systemd-nek eroszakosan loggolni (ha kikapcsolod akkor nincs logging egyaltalan meg az rsyslog sem kap semmit)

A boot korai szakasza után tényleg megkérdőjelezhető a döntés.

valamint a fejleszto kozosseg mentalitasa!

Eddig egy feature requestet dobtam be a bug tracker-ükbe, a hibajegy egyik felét szépen benéztem és RTFM kategóriás volt. Lennart válaszolt rá (pedig őt szokás minden gonoszság mintájának kikiáltani :) ), és leírta, hogy az egyik fele már megvan, a másik meg fele tényleg hasznos lenne és szívesen látnak minden kódot (csak időm és kedvem nem volt C-ben kódolni :) ). Szóval works4me :)

itt egy jo kis(hosszu) leiras arrol h mit akarnak
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.h…

És mi ezzel a gond? A kernelben van/lesz egy csomó kihasználatlan feature, amikből össze lehet rakni egy rendszert, ahol a disztrib készítők továbbra is függetlenek egymástól, az alkalmazások fejlesztőinek (és itt azért leginkább a zártakra gondolnak szvsz.) meg adnak egy rendszert, ahol a saját követelményüknek megfelelő alaprendszert kérhetnek maguk alá.

(a kapcsolódó HUP-os topikban már írtam, hogy kíváncsi vagyok az előadására, amit emleget a cikkben, mert így nem nagyon győzött meg, de pl. gondolj egy Steam-re fejlesztőre: ezzel a rendszerrel egy laza mozdulattal mondhatná azt, hogy ő a Steam Platform 1.3-at támogatja, és kap egy fix lib környezetet anélkül, hogy saját disztribet kellene csinálnia)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

pont a linket olvastam es nem ertem meg mindig mi a nagy gond vele. lehet h sietve olvastam de a HW address kiolvasasa majd sorbarendezes szerintem nem nagy falat.
viszont ahany gep annyi firmware. ahhoz hogy csinalsz autodeploy scriptet?

hostname
nem tudom nekem az jobban tetszik h ott van egy plain text fájlban és kész ellenben nyaggatni kell egy bináris szolgáltatást

fejlesztok es jovo
akkor te teljesen mas emberekkel talalkoztal es nem az eredeti unix iranyzatot tartod iránynak.
az h sok rendszert összebarkácsolnak egybe...hát nem tudom. majd meglátjuk mi lesz belőle.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

A HW address alatt a MAC címet érted (ami ugye nem feltétlenül van minden NIC-nek) vagy a hardware útvonalat (PCI/USB/... slot - ami ugye változhat, pl. egy olyan gépen, ahol USB-n van keresztül vezetve az Ethernet és a Wifi, a felismerés sorrendje nem garantált; ha meg USB eszközútvonal, akkor egy másik portba kötött eszköz újként jelenne meg)?

A hostnamed a hoszt neven kívül még jó pár tulajdonságot kezel (hostnamectl kimenetén látni lehet pl.). A plain text fájl meg oké, szép és jó, ha ismert és fix helyen van. Ami disztrib főverzión belül többnyire adott, azon túl...

akkor te teljesen mas emberekkel talalkoztal es nem az eredeti unix iranyzatot tartod iránynak.

Az eredeti UNIX irányzattal nincs gond, nem is sérül. Sok kis alkalmazás egy ernyőprojekt alatt (a megosztott könyvtárak miatt), mindegyik egy jól specifikált feladatot lát el. A sok rendszeres nem tudom, hogy erre, vagy a btrfs-es snapshotos akármilyen tervükre vonatkozik, utóbbira: ahelyett, hogy minden szoftverhez statikusan linkelve hozniuk kelljen a fél világot, a fél világot választhatóvá elérhetővé teszik - aminek van értelme, pl. egy CentOS 7-en a glibc verzióváltás miatt gyönyörűen segfault-ol az egyik statisztikai programcsomag(hoz mellékelt Java VM), ami RHEL6-on támogatott. Lennart-ék elképzelése szerint a stat. csomag simán mondhatja azt, hogy akkor én ide kérek egy RHEL6 base-t, itt a programom; és kapnak egy fix rendszert és glibc verziót, anélkül, hogy nekik kéne a fix rendszert megcsinálni és frissítéseket/javításokat kiadni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

akkor lehet h en vagyok out-of-date mert en ugy tudtam minden eszkoznek ami kommunikal TCP/IP alapu halozattal rendelkeznie kell MAC cimmel. Ha joltudom meg az USB dongle cuccoknak is van MAC cimuk. Lenniuk kell kolonben az Layer 3 nem tudja hogy hova tovabbitsa az adatokat.

oke, elfogadom a hostnamectl de miert kellett belerakni a dmidecode adatait is? Ez olyan erolkodesnek tunik mint Fedoran a firewall-cmd. Nem megtanulni hasznalni az iptables parancsokat, neeeem, adjunk egy python scriptet ami kieroszakol olyanokat amit az eletben nahasznalnal pl tobb zona. Nem vitatom a zona letjogosultsagat, de a legtobb embernek nincs ra szuksege.

a tobb verzios sw meg aztmondom h a fene vigye el a specialis programok fejlesztoit. miert segfaultol ujabb glibc?
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

MAC címe mindenképp van, csak az nem biztos, hogy állandó (van beégetett cím). Beágyazott rendszereknél előferdül, pl. mert a gyártó nem akart címtartományt venni magának.

Mármint azokat az iptables parancsokat, amiket pár éven belül le fogunk cserélni a NFTables-re? :) Ha van egy jól határolt modelled arról, hogy hogyan akarod a hálózatod látni (ez ugye a firewall-cmd zóna-szolgáltatás-interfész stb. modell), abból tudsz képezni iptables, nftables, BSD-s random filter stb. szabályokat. Egy iptables szabályrendszerből nem feltétlenül. (a másik oldalról: remélem, hogy elterjed, nincs szebb annál, hogy ahány disztró, annyi iptables service, amit jó esetben használnak, rosszabb esetben rc.local-ból hívogatott iptables...

Nem a glibc segfaultol, csak felette a program :) [igazából idáig jutottam a strace-ben, ha jól rémlik egy memcpy akad el - ugyanaz a szoftver CentOS 6-on gond nélkül ment]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"minden eszkoznek ami kommunikal TCP/IP alapu halozattal rendelkeznie kell MAC cimmel"

Egy pppd kapcsolat rendelkezik IP címmel, kommunikál TCP/IP alapú hálózattal - nincs MAC címe.
Egy OpenVPN kapcsolatot ha tun alapokon konfigurálsz, rendelkezik IP címmel, kommunikál TCP/IP alapú hálózattal - ennek sincs MAC címe.

A MAC address és az IP cím két külön szint, mindkettő simán működhet a másik nélkül.

( zephyrus | 2014. 09. 17., sze – 11:32 )

kicsit sok volt a komment nem olvastam végig, de mysql talán már nincs is csak mariadb, azt pedig így indítod újra:

systemctl start mariadb

az új network kezelést személy szerint még nem is tudom hogyan kell használni, mert neten rákeresek static ip beállításra centos 7-en, első dolog, hogy kikapcsoltatják a networkmanagert és akkor működnek a network scriptek

-- "az új network kezelést személy szerint még nem is tudom hogyan kell használni, mert neten rákeresek static ip beállításra centos 7-en, első dolog, hogy kikapcsoltatják a networkmanagert és akkor működnek a network scriptek"

Ha ez igy van, surgosen keress tovabb ilyenkor. Ez pont ugyanaz, mint amikor azt javasoljak, hogy "Z alkalmazas mukodesehez kapcsold ki a SELinuxot" (Ha legalabb azt javasolnak, hogy kapcsold permissive modba, de nem *KI* .) De meg egyszerubb pelda, "kapcsold ki a tuzfalat", mert az fogja meg a mukodeshez szukseges halozati forgalmat.

Szoval maradjunk annyiban hogy en is ruhellem a systemd-t, de tavalyi joslatom ellenere ugy tunik erre megy a vilag, mindenkinek meg kell vele baratkoznia (nekem is, bar egyelore NO PASARAN!)

Én éppen ezekkel játszom, mármint tegnap pl. a NetworkManagerrel. Van vele némi szenvedés, meg meglepő dolgok (pl. az interface csak addig van felhúzva, amíg konzolon be van lépve valaki, WTF?), de beállítható vele minden és működik jól. Két dolog azért tény:

1. Nincs róla jó doksi. A RHEL7 hivatalos doksija nagyon-nagyon rossz.
2. Nem a 40 éve jelenlevő "szerver a szerverteremben statikus IP-címmel" dologhoz tervezték, hanem az ennél (sokkal) dinamikusabb és dinamikusabban változó hálózati megoldásokhoz (pl. "3G és wifi hálózatok tömkelege között vándorló tablet", "dinamikusan allokálható virtuális desktopok" meg hasonlók).

De tök hasonló egyéb dolgok is vannak a RHEL7/Centos7-be, amelyekben a bevezetésükkor dönteni kell, pl.:

- firewalld (mi a péknek egy, az iptables-nél sokkal logikátlanabb absztrakciós réteg az iptables fölé? szeretném szeretni, de egyelőre nem nagyon megy...)
- chrony vs. ntp (melyikkel szinkronizáljam az időt? mi a pékért a chrony a default?)
- /tmp tmpfs-re vagy fájlrendszerre menjen?

Cserébe van egy, ami nem kérdés: van az OS-be integrált vmware-tools, nem kell vele szenvedni, juhéj!

"interface csak addig van felhúzva, amíg konzolon be van lépve valaki, WTF?"
Tippre beallitottad hogy user specifikus legyen az interface, talan valami olyan neven fut hogy available to all users, ha az nincs kipipalva akkor csak akkor aktiv ha be van lepve a user.

"chrony vs. ntp (melyikkel szinkronizáljam az időt? mi a pékért a chrony a default?)"
chrony jobb laptopokra meg olyan gepekre ahol nincs folyamatos vagy stabil net kapcsolat, kevesbe pontos mint egy ntp de jobban elviseli ha tartosan nem tud lekerdezni, elcsuszik a szinkron emiatt.

"/tmp tmpfs-re vagy fájlrendszerre menjen?"
Ahogy jol esik, ha van memoria es/vagy sokminden irogat oda akkor erdemes tmpfs-nek tenni.

Én sem találtam normális leírást a Network Managerhez, akkor lehet nem véletlen.
Mi az értelme bevezetni a Network Managert, ha nem lehet megfelelően használni általános server hosting célra, mert nincs jól dokumentálva? Azért szervereknél nem extra, hogy hálózaton vannak... :)

Sakk-matt,
KaTT :)

( talisker | 2014. 09. 18., cs – 11:34 )

Érdemes esetleg elolvasni a Red Hat Enterprise Linux 7 Migration Planning Guide-ot.
Abban össze van szedve, hogy mik a lényegi különbségek, mik az ajánlások, hogy mit hogy kéne csinálni.

Annak ellenére, hogy Fedoraban mar ezek jó részét régóta használom, eléggé értékesnek tartom a fenti művet,
mivel témakörönként összeszedi, hogy mi merre.

Networking oldalon azért a CentOS6 is bírt érdekes dolgokat művelni NIC naming tekintetben.
Több hálókártya esetén nekem mindenképpen udev rule-okat kellett definiálnom, hogy a kívánt HW kártya kapja a kívánt elnevezést konzisztensen.

Egyébként meg lehet használni a régi network kinfigolást is, NetworkManagert nem kell felrakni és kész.
Systemd vs init - inkonzisztencia meg szívás alapvetően a trehány init scriptek miatt bír/bírt lenni tapasztalataim szerint.
Minden egyéb pro-kontra érv helyet szimplán nekem kompaktabbnak hat a systemd.

Ahogy mások már jeleztés, a SysV service hívás átmegy a systemd-n, ezt a "semi kompatibilitást" megcsinálták.
Ha valaki meg direkt hívogatta az init.d alatt a scripteket, az meg tán szokjon át róla.
A RHEL4/CentOS4 óta biztosan (de lehet, hogy régebb óta) van a service parancs az initscriptek piszkálására.

Persze ízlések és pofonok ... de ezektől szerintem a CentOS7 cseppet sem "rosszabb", mint bármelyik elődje, sőt.

Előre a Lenini núton - tanulni, tanulni, tanulni ... :)
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

KISS - az initscrptek olvasható, értelmezhető dolgok voltak, egyértelmű volt, hogy mi, merre található (akinek nem, mert csak a fusimusibinugz 1.2.3.tré-23béla verzióját használta "világ életében" (ami nem több 2-3 évnél) az így járt...). És nem mellékesen polcfolyóméterben számolva kilométerekre rúg úgy a sysvinit, mint a BSD-style init megoldásnak a szakirodalma.

Hogyha neked a sysvinit "összehányt" dolog, akkor mi a véleményed a BSD-style initről? Na abban lehetett igazán gányolni...

Az initscriptek olvasható és értelmezhető zajt tartalmaztak... http://0pointer.de/blog/projects/systemd-for-admins-3.html itt jó példának hozza az abrt.service-t. 115 sor, egész pontosan három érdekes dologgal (a három változó az elején) - kb. pont azzal, amit a unit fájlba is tennél. Egy bonyolultabb init script (mondjuk egy named) több száz sor, külső konfigurációtól függ stb., pl. azért, hogy chroot-ba legyen zárva. Ami a systemd-vel egy sor. Fejből: RHEL-en, SLES-en és Debian-on hol tudod állítani/megnézni a named chroot elérési útját, ha ennyire egyértelmű és triviális, hogy mi hol van?

És igen, van olyan, hogy az init script értelmes dolgot csinál, jól, és nem egy sima sablon. Csak ritka. Ilyenkor meg bőven lehet írni egy unit fájlt, ami azt a scriptet indítja.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)