Re: наследяване на сървъри

Вместо да гледаш всеки /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
Lug-bg-R/uZOSXD/[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg