Centralizalt Patch/Software management Linux ala (Webes GUI, Free)

Segédprogramok

Sziasztok!

Tudtok valami alkalmazast amivel egy webes feluleten kozpontilag latnam ,hogy a felvett Linuxos rendszerek (Debian, Ubuntu foleg, 1-2 CentOS) hogy allnak csomag (Apt,Yum)ugyileg?

A lenyeg, hogy nem kell olyan megoldas, hogy ez az app deploy-olja is a csomagokat, csak egy webes osszesitett listat szeretnek latni, ilyen tablazatszeruen, szepen a gepek egymas alatt, es jelzi ha frissiteni kell, stb...

A Webmin-t hasznalom, de olyan lenne jo, ahol egy felulet alatt latok minden gepet.

Nem lenne rossz, ha igy installalni is tudnek uj csomagokat, illetve ha idozitett futtatast is be lehetne allitani.

Letezik ilyen program, lehetoleg free-ben, illetve a konkret "kozpontilag deployolt csomagok" funkciok nelkul? (arra nincs szuksegem, mert apt-proxyt hasznalok)

  • 4039 megtekintés

( _Gabor_ | 2019. 02. 28., cs – 10:37 )

Debian/Ubuntu alatt a /usr/lib/update-notifier/apt-check megmondja, hogy van-e frissítendő csomag.
Ha csak a biztonsági frissítésekre vagy kíváncsi, akkor
/usr/lib/update-notifier/apt-check 2>&1| awk -F\; '{print $NF}'

Ezt kösd be monitoringba és akkor annak a webes felületén látod majd, hogy melyik gépeket lenne már célszerű frissíteni.

Red Hat Satellite 6 is a re-engineering of the Red Hat Satellite product. Spacewalk (and its downstream product, Red Hat Satellite 5) is a systems-management tool, and Satellite 6 is designed to accomplish the same set of goals. However, Satellite 6 has been built from the ground-up on different and more modern technologies. Spacewalk is not the upstream for Satellite 6, and never will be.Instead Satellite 6 is a federation of several upstream open source projects, including Katello, Foreman, Pulp, and Candlepin.

A Satellite 5 -re már csak 2020.05.31 -ig van support. Ma már érdemben a 6-os széria jelenti a Satellite -ot.

( zwei | 2019. 02. 28., cs – 15:44 )

Régóta keresek ilyet én is, de egyelőre nem találtam.
(sub)
Találtam valami online szolgáltatást, ami tudta ezeket, teszteltem, nem volt rossz, de ilyen feladatra csakis self-hosted cucc jöhet szóba nálam.
Azt hiszem ez volt az: https://www.automox.com/

Az agent kapcsolódik a szolgáltatáshoz X időnként, elég ha kilát a szerver netre, nem kell portot forwardolni.

Nem az a baj, hogy neten legyen a szerver vagy sem, hanem, hogy harmadik félnek gyakorlatilag minden infót kiad a szerverről. (Patchelni is lehet vele, szóval root jogot is.)

Egyébként teszteltem azt a szolgáltatást egy eldobható VM-el, és jó volt, csak ne cloud service lenne....

( quash | 2019. 02. 28., cs – 17:33 )

nagios check_apt (debian, ubuntu csomagban) + ansible v. hasonló a frissítésre.

( ScOut3R | 2019. 02. 28., cs – 22:58 )

AWS SSM Patch Manager. A kliensek pull alapon mukodnek, tamogat sajat, belso repot illetve van kezdetleges compliance reporting.
Run Command funkcioval tetszolegesen frissithetsz, illetve a Maintenance Window-val automatizalhatod.
Lambda es Step Functions hasznalataval gyonyoru logikat lehet epiteni.

( Vamp | 2019. 03. 07., cs – 08:10 )

Uj info, ha valakit esetleg erdekelhet:

Csak nekiveselkedtem egy Spacewalk installnak. :)

Nem volt egyszeru Ubuntu kliensel osszehozni, de mar egesz jol allok, par apro dolgot kell lekuzdeni :)

# Eloszor is a 2.8-as verziot hasznalom, a 2.9-nel fol van tuntetve, hogy gond van a .deb package-ekkel.

# Selinux bekavart, permissive-re tettem... (2.9-nel erdekes modon nem volt ilyen gond)

# A szerver ezek utan telepult rendesen.

# Channels-nel arra figyelni kell, hogy nem x86_64 kell, hanem amd64-debian. Nekem fel ora volt, mire rajottem...:D

# Kliensnel volt gond rendesen :)

# Telepiteni a csomagokat, 18.04-ben nincsenek benne, en folvettem regebbi repot

apt-get install apt-transport-spacewalk rhnsd

# apt-secure kikapcs.... sajna muszaj, ez benne van a spacewalk doksiban...

nano /etc/apt/apt.conf.d/90insecure

Acquire::AllowInsecureRepositories "true";

# lenti fajlt szerkezteni az adott sorban a "0"-at "X"-re atirni. Szitnen doksibol van az info, kell es kesz :)

/usr/share/rhn/up2date_client/debUtils.py

-- a/usr/share/rhn/up2date_client/debUtils.py
+++ b/usr/share/rhn/up2date_client/debUtils.py
@@ -28,7 +28,7 @@ def verifyPackages(packages):

def parseVRE(version):
epoch = ''
- release = '0'
+ release = 'X'
if version.find(':') != -1:
epoch, version = version.split(':')
if version.find('-') != -1:

# Ezek kellenek a kliens regisztraciojahoz a szerveren

wget http://spacewalk.local/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT

rhnreg_ks --serverUrl=https://spacewalk.local/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-"my-key"

# ketszer kell update-elni :)

apt-get update

apt-get update

# Ami ez utan jon, az mar opcionalis. Alapbol 4 orankent hajtja vegre az utemezett feladatokat a kliens, de ha beallitjuk rajta a OSAD funciot, akkor megy azonnal a deploy.

# Csomag persze nincs a taroloban, de innen letoltheto: https://launchpad.net/~mj-casalogic/+archive/ubuntu/spacewalk-ubuntu/+p…

dpkg -i pyjabber_0.5.0-1.4ubuntu3.all.deb
dpkg -i osad_5.11.27-1ubuntu1.all.deb

service osad start
update-rc.d osad defaults

Jelenleg itt tartok, minden megy, tudok csomagot frissiteni, etc... viszont az OSAD meg nem akarja az igazat... Valszeg a gond az FQDN-el lesz, ezen leiras szerint: https://purplepalmdash.github.io/2015/08/12/trouble-shooting-on-spacewa…

A 4 oras utemezest amugy at lehet allitani, szoval az OSAD mar csak "extra" de jo lenne, ha az is menne, ahogy kell.

Majd ha valakit erdekel meg, irok, mire jutottam.

Kozben helyretettem az OSAD-ot. kellett a megfelelo FQDN, illetve az osad-servert kellett a serveren elinditani.

Most mar megy az azonnali push.

Par kerdesem/pici gondom van meg csak:

a kerdes:

szerintetek ubuntu 18.04-hez jok ezek a repok, vagy van koztuk folos?

bionic-backports main
bionic-backports restricted
bionic main
bionic restricted
bionic-security main
bionic-security restricted
bionic-updates main
bionic-updates restricted

A masik kett inkabb "problema"

Ezeket a csomagokat nem frissiti, valszeg azert mert mas repobol jonnek, mas nevvel, de a verziojuk ugyanaz:

gcc-8-base-8-20180414-1ubuntu2.amd64-deb - gcc-8-base-8.2.0-1ubuntu2~18.04.amd64-deb
libgcc1-8-20180414-1ubuntu2:1.amd64-deb - libgcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
libgomp1-8-20180414-1ubuntu2.amd64-deb - libgomp1-8.2.0-1ubuntu2~18.04.amd64-deb
libstdc++6-8-20180414-1ubuntu2.amd64-deb - libstdc++6-8.2.0-1ubuntu2~18.04.amd64-deb

Ezt szerintetek ki lehet vedeni valahogy?

Illete van otletetek, hogy a gitlab repojat hogyan tudnam hozzaadni?

https://packages.gitlab.com/gitlab/gitlab-ce/

Legutoljara amikor neztem, csak IPv4-en mukodott, ugyhogy le kellett csapnom a gepen az IPv6-ot (egyszerubb volt, mint kiveteleket varialni hozza).

deb https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ bionic main
deb-src https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ bionic main

szerk: amugy az install doksiban benne van, hogy nyugodtan telepithetsz ee package-et, licence nelkul gyakorlatilag CE, nekem igy van. (bar az 'Enable CI' panel az agyamra megy, azt orulnek, ha ki tudnam kapcsolni, Jenkins tok jol elvan, meg ha valamit elkefelek veletlenul, akkor sem rantom vele a repokezelot).

( Vamp | 2019. 03. 09., szo – 14:12 )

Mivel lattam, hogy paran sub-oltak a temat, ezert kis info.

A Suse Managernek eddig ugyanugy a Spacewalk volt az alapja, mint a Red-Hat-nak, most viszont (nem kizart, hogy az miatt, hogy a Red-Hat kihatral a Spacewalk mogul) Forkoltak a Spacewalkot, "Uyuni" neven. (nem mostansag volt a dolog, meg tavaly majusban volt a bejelentes, oktober vegen pedig az elso release) Nem mellesleg ezentul az Uyuni lesz a Suse Manager upstream-ja a Spacewalk helyett. A bejelentesben anno belengettek az Ubuntu 16.04 es 18.04 supportot, jelenleg nem tudom hogy all a dolog, de elkepzelheto, hogy teszt kornyezetben ra fogok nezni, majd jelzem a tapasztalatokat.

A link: https://www.uyuni-project.org/

Egyeb: A Spacewalk kis tuning utan egesz jol bevallt amugy Debian/Ubuntu alatt, most veszem fol a klienseket.

Illetve meg mindig kerdes, hogy melyik repokat erdemes szerintetek folvenni a csatornakhoz a ket disztronal? (csak alap programokhoz, frissiteshez)

Na gyorsba home laborban kiproblatam az Uyuni-t. Igeretesnek latszik, picit mintha jobban "kezre allnanak" benne a dolgok, mint a Spacewalkban. Ahogy fontebb is ajanlottak a Spacewalkhoz, a Uyuni-ban a Salt "gyarilag" be van epitve, ami a kliensek kezeleset elegge leegyszerusiti.

Ubuntu tamogatas keszul, elv "hamarosan" elerheto lesz: https://github.com/uyuni-project/uyuni/pull/461

Most a bekonfigolt Spacewalkot nem dobnam el ez miatt, viszont ha tenyleg jobb Ubuntu/Debian supportot tudnak adni akkor elgondolkodom a kesobbiekben raja. Jelenleg csak figyelemmel kiserem, mi lesz a dologbol.

( Vamp | 2019. 03. 12., k – 20:50 )

Friss helyzetjelentes, ha meg valaki olvassa :)

Ami a legutobbi ota siekrult megoldani:

- Dupla csomagokat szurtem repo sync szinten, igy eltuntek azok a csomagok, amik duplikaltan szerepeltek (mert jottek update es main repobol is)

- Errata adatokat Ubuntu es Debian rendszerbe is sikerult betenni! Juhhee! (reszletek: https://github.com/philicious/spacewalk-scripts)

Amivel meg kuzdok:

- Harmadik feltol szarmazo repok (Docker, Gitlab...)

- GPG signing (lehet hanyagolom amugy, de itt van rola egy leiras, csak meg nem melyedtem bene: http://www.devops-blog.net/spacewalk/gpg-signing-apt-repository-in-spac…)

Lentebb linkeltem a friss csomagokat, sajnos viszont azok meg eleg bugosak...konkretan nalam is az alabbi jelentkezett: https://www.redhat.com/archives/spacewalk-list/2019-January/msg00042.ht…

Igen, osszeszedni es dpkg -i vel telepiteni lehet jobb megoldas lenne, viszont ahogy neztem, mas nem nagyon jon a 16.04-es tarolobol, csak a szukseges fuggosegek. (Aztan telepites utan ugye a script ki is szedi a repot)

( x-daemon | 2019. 03. 13., sze – 14:17 )

aztan minek nezegetned? :)
apt-get install unattended-upgrades needrestart

--
neked aztan fura humorod van...