Correcties
modified: data/config.json modified: data/info.md modified: posts/24Jul-SyncRepo.md modified: posts/24Jun-zabbix-prom.md modified: posts/27Sept-GitlabUpgrade.md modified: posts/31Jul-SELinux.md
This commit is contained in:
Eli Winderickx
@@ -52,7 +52,7 @@ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-SLACK
|
||||
```
|
||||
|
||||
Als we dan info opvragen van de software, zien we alle relevante informatie maar ook dat deze van onze lokale repo afkomstig is. Hier heb je zo'n voorbeeld van:
|
||||
|
||||
|
||||
|
||||
Handig om te weten maar opnieuw niet handig als we honderden softwarepakketten hebben. Gelukkig kunnen we bestaande repo's ook volledig synchroniseren.
|
||||
|
||||
|
||||
@@ -13,21 +13,21 @@ Zabbix kan heel veel, ook verbinden met de Prometheus clients; `node_exporter` e
|
||||
## Het master-item
|
||||
Het belangrijkste zit in de master-item. Deze gaat namelijk via een `HTTP-item` de pull doen naar de `node_exporter` host. Net als bij de Prometheus server krijgen we ineens alle data binnen van de host. Zabbix kan daarna extra `Dependant items` maken op basis van verschillende entries in het `master`-item. Geef het adres van de host in onder URL en vervolledig met `:9100/metrics`. Voor testdoeleinden kan het interessant zijn om even geschiedenis bij te houden maar daarnaast is dit heel veel data die we niet moeten bijhouden en dus kunnen we onder `history storage period` 0 zetten. Let daarnaast dat `Type of information` Text is.
|
||||
|
||||
|
||||
|
||||
|
||||
## Dependant item
|
||||
Nu het `master`-item aangevuld wordt, kunnen we een nieuw item aanmaken en die van het type `Dependant item` maken. De naam en key moeten zoals steeds uniek zijn en onder `master`-item kunnen we het item van zonet hier aanvullen.
|
||||
|
||||
|
||||
|
||||
|
||||
Onder het tab `Preprocessing` gebeurt nu het interessante en gaan we aangeven welke waarde we uit ons Master-item willen halen. In deze context kunnen we enkel gebruik maken van `keys` en `values` en hebben we dus echt enkel de specifieke metrix die we ophalen.
|
||||
|
||||
|
||||
|
||||
|
||||
## Low-level Discovery
|
||||
Via LLD kunnen we iets gemakkelijker verschillende items op een geautomatiseerde manier ophalen. We hebben nog steeds ons `master`-item nodig als vertrekpunt. Hierna kunnen we enkele leuke zaken definiëren. Nadat we Naam, key en `master`-item hebben opgegeven, kunnen we naar `Preprocessing` gaan en daar `Prometheus to JSON` selecteren. Als Parameter kunnen we nu een `Prometheus pattern` ingeven alsook wat regex om enkele zaken variabel te laten opvullen.
|
||||
|
||||
|
||||
|
||||
|
||||
Hieronder een voorbeeld van zo’n JSON verwerking
|
||||
````JSON
|
||||
@@ -74,5 +74,5 @@ In bovenstaand voorbeeld kunnen we enkele waarden terugvinden zoals `name`, `hel
|
||||
|
||||
Tot slot kunnen we nu een `prototype item` aanmaken. Door de LLD Macro’s, kunnen we nu eenvoudig unieke waardes genereren. Onder Preprocessing, kunnen we dan opnieuw die Macro’s gebruiken om de juiste waarde te selecteren.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -13,12 +13,12 @@ Helaas pindakaas! Als we niet het juiste pad volgen, brengen we onze Gitlab inst
|
||||
### Maak snapshots!
|
||||
Servers zijn vaak gevirtualiseerd. Iedere productiewaardige virtualisatiesoftware biedt snapshots aan en ook hier wil je daar gebruik van maken. Vóór iedere upgrade maak je best een snapshot en dan kan je met een gerust hart er in vliegen.
|
||||
|
||||
|
||||
|
||||
|
||||
### Lees de documentatie
|
||||
Gitlab maakt goed tijd vrij om duidelijk te maken aan gebruikers wat er verandert in de verschillende versies. Daar ga je ook terugvinden wat er achterliggend zou verandert zijn, waar jij op moet letten of waarom je na een succesvolle upgrade niet meteen aan de volgende mag beginnen.
|
||||
|
||||
|
||||
|
||||
|
||||
### Communiceer!
|
||||
Gebruikers die actief zijn op jouw Gitlab instantie moeten weten dat je de upgrade gaat doen. Dat betekent dat ze tijdelijk niet op hun Gitlab kunnen rekenen. Eventuele automatische installaties zullen dus ook even niet lukken.
|
||||
@@ -32,7 +32,7 @@ Als je gebruik maakt van een RHEL gebasseerde server en je hebt Gitlab met de re
|
||||
sudo dnf list gitlab-ee --showduplicates
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
In mijn voorbeeld, dat expres verouderd is, zit ik op versie 15.10.2. Alles wat daarboven staat zijn de oude versies en alles eronder de nieuwe.
|
||||
|
||||
@@ -46,7 +46,7 @@ sudo dnf upgrade gitlab-ee-15.10.8
|
||||
|
||||
> Nadat de installatie klaar is, gaat jouw Gitlab misschien nog niet online zijn. Wacht tot je terug aan jouw Gitlab kunt voordat je deze gaat updaten.
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# Daarna is 15.11.0 de eerst volgende versie voor mij
|
||||
@@ -70,7 +70,7 @@ sudo dnf upgrade gitlab-ee-16.3.4
|
||||
sudo dnf upgrade gitlab-ee-16.4.0
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Voor je gaat...
|
||||
Het was een heel werkje om Gitlab vanaf een oudere versie up-to-date te brengen. De beste raad die ik je dan kan meegeven is de upgrades zo regelmatig mogelijk uit te voeren. Volg in Gitlab de officiële versies en voer een update uit zo snel als het past. Opnieuw lees de documentatie voor je die uitvoert om zo tranen te vermijden.
|
||||
|
||||
@@ -35,7 +35,7 @@ ps auZ
|
||||
# ...unconfined_u:unconfined_u:unconfined_u:s0-s0:
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
De `SELinux` context kan opgedeeld worden door middel van het `:` teken. Het eerste deel slaagt op de `user mapping`, vervolgens `role`, dan `type` en het laatste gedeelte is het level. Dit level is relevant in de `multi-level security` policy.
|
||||
|
||||
@@ -104,7 +104,7 @@ server {
|
||||
|
||||
Als we nu de website proberen te benaderen krijgen we nu een error in het audit log. Ik heb zelf die map aangemaakt en deze heeft nog niet de juiste security context. Dat kunnen we aanpassen!
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# We kennen de juiste security context toe aan de map
|
||||
@@ -116,7 +116,7 @@ Omdat we heel Agile werken, heb ik nieuwe bestanden geüpload naar mijn persoonl
|
||||
```
|
||||
mv ~/myNewIndex.html /srv/www/public_html/index.html
|
||||
```
|
||||
|
||||
|
||||
|
||||
```
|
||||
restorecon -R /srv/www/public_html/
|
||||
|
||||
Reference in New Issue
Block a user