Вместо да гледаш всеки /etc/init.d script провери кои са инсталирани от rpm package rpm -qf /etc/init.d/xxxx другите ще трябва да ги чекнеш на ръка :)
след това за всички тези пакети пусни един verify: rpm -V rpm_package това цялото освен ако SuSE не е безумно старо :) Нещото от което найстина трябва да те е страх в SuSE е някой да не е пипал дирекно conf files а да не е ползвал yast/yast2 :))) има много хора които сега биха ме hate-нали :) но те си знаят :) преди да правиш каквото и да било :)) защото се чуха разни патчвай и тн :) това хубаво ама ако намажеш нещата си загубен :) направи си копие на машината което можеш да restor-неш 1000000% и да я имаш работеща за по малко от час :) тогава ръгай :) tools колкото искаш аз лично бих направил един ReaR за да съм сигурен :) или ако имаш mirror го счупи докато ръгаш и ако скапеш sync на обратно! Успех! 2013/6/20 Yordan Radunchev <[email protected]> > > > > On Thu, Jun 20, 2013 at 11:11:20AM +0300, Peter Pentchev wrote: > > On Thu, Jun 20, 2013 at 10:58:17AM +0300, Peter Pentchev wrote: > > > On Thu, Jun 20, 2013 at 10:30:43AM +0300, Vasil Kolev wrote: > > > > В 07:23 +0300 на 20.06.2013 (чт), Yordan Radunchev написа: > > > > > Хора, попадали ли сте в ситуация да ви връчат сървър, за който > няма нито ред документирано? > > > > > Какво работи, защо работи, кой го ползва? При това сървъра си е > production, има над 400 дена > > > > > ъптайм, ползва се сериозно... Какво правите в такава ситуация, > какви са стъпките за > > > > > инвентаризиране? Идентифицарне на потребителите в passwd, на > сървисиз...? От къде почвате и > > > > > как бихте подходили? > > > > > > > > > > r., > > > > > yra > > > > > _______________________________________________ > > > > > > > > > > > > Принципът е да разбереш какво точно се случва на машината (какво > прави, > > > > какви услуги и хора има на нея), да ограничиш достъпа на който не > трябва > > > > да го има и да почнеш малко по малко да update-ваш каквото има нужда > > > > (щото всичко с 400 дни uptime поне kernel трябва да му се смени). > > > > > > > > Може да тръгнеш от отворените портове или процесите в ps auxw, може > > > > първо от passwd файла, от инсталираните пакети (въпреки че това е > малко > > > > тежко) и т.н., > > > > > > ...от startup скриптовете (макар че това напоследък е малко сложно - > > > допреди пет години си имахме SysV-style init scripts и BSD-style init > > > scripts, после се нароиха всякакви upstart-и (а тук каква игра на думи > > > има...) и какво ли не). Като при гледане на startup-скриптовете не > > > забравяш две, не, три, уф, не, четири неща: > > > > > > - не само имената на скриптовете; понякога може да си заслужава да > > > вземеш да ги отвориш, за да видиш дали някой кръгъл иди... така де, > > > администратор с много опит и оправдано самочувствие не е решил да > > > променя нещо директно в тях, а не в конфигурационните им файлове > > > > Тази точка може да бъде силно улеснена, ако администраторът не е бил > > твърде откачен и ти е оставил система, в която повечето, ако не всички, > > startup-скриптове са инсталирани през някаква пакетна система, която > > пази контролни суми на файловете и можеш с една команда да ги провериш. > > > > Поздрави, > > Петър > > > > Благодаря, много ценни съвети. Захващам се. Системата е SLES, има си > zypper, ще ми каже поне > нещата инсталирани през него. Ще му пусна и cfg2html - ще спести малко > време. Но идеята да > се отварят стартъп скриптовете е златна - наистина има вероятност да е > мазано вътре и един > бог знае какво всъщност пускат. > > Сървърите са 5, на един от тях намирам puppet... но ме е страх да се > надявам още, че е > използван за всичките, върде лесно би било. По тях са работили доста хора > във времето, > повечето от които в момента вече не работят тук. Последно на един индиец > са били поверени, > но той е бил в същото положение в което съм и аз. Отделно с него не > говорим един английски, > та ще е трудна комуникацията... > > R., > yra > > > _______________________________________________ > Lug-bg mailing list > [email protected] > http://linux-bulgaria.org/mailman/listinfo/lug-bg > >
_______________________________________________ Lug-bg mailing list [email protected] http://linux-bulgaria.org/mailman/listinfo/lug-bg
