Naar de inhoud

Documentatie

Integraties

Een integratie is één systeem waar je agent namens jou mee praat: een hypervisor, een controlepaneel, een gamepaneel. Deze pagina beschrijft wat ze gemeen hebben: hoe je er een koppelt, wat Provibr ermee mag, en hoe je vaststelt of het echt werkt.

Eén register, geen stapel uitzonderingen

Elke provider staat op één plek beschreven: bij welke categorie hij hoort, wat voor resource hij oplevert, welke inloggegevens hij nodig heeft, en welke van de zeven mogelijkheden hij heeft. Het paneel, het platform en de agent lezen allemaal diezelfde beschrijving. Nergens in het product wordt gevraagd of een systeem toevallig Proxmox is.

Daarom verschillen de tabbladen van een integratie per provider. Een tabblad Test bestaat omdat de provider een verbindingstest aangeeft; een tabblad Besturingssystemen bestaat omdat de provider templates kan bevatten; een tabblad Importeren bestaat omdat de provider kan opsommen wat hij al draait. Een ontbrekend tabblad is een ontbrekende mogelijkheid, geen pagina die niet laadde.

De categorieën

Hypervisor
Draait virtuele machines en geeft de hele machine uit: cores, geheugen, schijf, netwerk. Welke hypervisors live zijn en welke op de roadmap staan, staat op de integratiepagina.
Controlepaneel
Draait webhostingaccounts op een machine die al staat. Het maakt een account aan met een pakket, niet met een besturingssysteem. De integratiepagina labelt elk controlepaneel live of roadmap.
Gamepaneel
Draait containers met gameservers, gebouwd uit een recept in plaats van uit een image van een besturingssysteem. Het staat naast de controlepanelen en niet erin, omdat bijna niets aan die twee hetzelfde is. De integratiepagina toont de gamepanelen die live zijn.
Dedicated
Fysieke machines, geïnstalleerd over het netwerk en out of band bediend. Aangekondigd en niet gebouwd.
Netwerk
Switches en routers. Aangekondigd en niet gebouwd, en het verschijnt helemaal niet op de integratiepagina, want netwerkapparaten hebben hun eigen schermen en tellen niet als resource.

Wat een provider kan

Zeven mogelijkheden bepalen wat er verschijnt en wat het platform bereid is te versturen. Een opdracht die een mogelijkheid nodig heeft die de provider niet heeft, wordt geweigerd voordat hij bij je agent is, met de reden erbij.

  • Console: een live scherm of terminal op de resource.
  • Firewall: het platform kan afdwingen welke adressen een resource mag gebruiken.
  • Firewallregels: een geordende regellijst die je zelf bewerkt, plus het firewall-log.
  • Hardware: schijven en netwerkkaarten die je kunt toevoegen, vergroten en verwijderen.
  • Metingen: verbruiksmetingen, en dus grafieken.
  • Besturingssystemen: templates of images waaruit het platform kan installeren.
  • Adrestoewijzing: Provibr bepaalt welk adres de resource krijgt.

Er een koppelen

Een integratie toevoegen gaat in drie stappen: het soort systeem, de verbinding en de inloggegevens. Een categorie waar nog niets achter gebouwd is, is zichtbaar maar niet te kiezen, zodat je ziet wat eraan komt zonder het te kunnen selecteren.

  • Je kiest een agent én een provider. Die agent gaat het systeem bereiken, dus hij moet op een netwerk staan dat dat kan.
  • De naam is van jou. Het is een label in het paneel en niets anders leest hem.
  • De inloggegevens worden gecontroleerd tegen dezelfde regels die de agent hanteert, daarna naar die agent gestuurd en in zijn kluis versleuteld. Je blijft op de pagina tot de agent antwoordt.
  • Weigert de agent ze, dan zie je de reden en blijven de waarden die je typte staan, zodat één typefout je niet het hele formulier kost.

Wat er bewaard wordt en wat niet

De inloggegevens worden nooit naar de database van het platform geschreven. Wat bewaard blijft zijn de namen van de velden die je invulde, en de host en de poort, zodat het paneel iets te tonen heeft en het auditspoor ergens naar kan wijzen.

Daarom kun je inloggegevens niet bekijken of bewerken, alleen opnieuw versturen. Het formulier begint elke keer leeg. En daarom kan ook niemand bij Provibr ze lezen.

Op de host zijn ze versleuteld met een sleutel die vermengd is met de identiteit van die machine. De kluis en zijn sleutel naar een andere machine kopiëren levert niets op. Het beschermt niet tegen root op je eigen host. Die host is van jou, en de inloggegevens ook.

TLS-fingerprints

Elke provider die HTTPS spreekt heeft een veld voor een fingerprint. Vul hem in en de agent accepteert alleen nog het exacte certificaat dat je gepind hebt, en dat is wat een self-signed certificaat op je eigen node veilig bruikbaar maakt. Neem de fingerprint vanaf de agent-host, dan pin je wat de agent straks werkelijk ziet:

shell
openssl s_client -connect <host>:<port> </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256
Een fingerprint naast een onversleutelde host wordt geweigerd in plaats van genegeerd, omdat hij een bescherming zou suggereren die daar niet kan bestaan.
Commando's en terminaluitvoer zijn overal Engels, in het paneel en op deze pagina's. Één tekst, één waarheid: wat je hier leest is letterlijk wat je host teruggeeft.

De checklist voor het inrichten

Actief betekent alleen dat de agent je inloggegevens heeft aangenomen. Het betekent niet dat de integratie klaar is om machines uit te geven. De checklist boven de tabbladen laat zien wat er nog ontbreekt en linkt er rechtstreeks naartoe.

  • Inloggegevens: bij de agent afgeleverd en aangenomen.
  • Instellingen: de niet-geheime keuzes die de provider nodig heeft, zoals welke node en welke range vmid's. Een provider die niets te kiezen heeft slaat deze stap over in plaats van hem als onaf te tonen.
  • Installatiemethode: of machines van een template gekloond worden of over het netwerk geïnstalleerd.
  • Besturingssystemen: minstens één image gekoppeld, voor de methode die je koos.
Geen enkele stap is een garantie. De checklist controleert dat dingen ingevuld zijn, niet dat ze kloppen. Daar is de test voor.

De verbinding testen

De testknop zet een echte aanroep naar je systeem in de wachtrij, uitgevoerd door je agent, en toont wat eruit kwam. Wat hij meldt verschilt per provider, omdat wat een verbindingstest zinnig kan zeggen volgt uit de API van dat product.

  • Proxmox: de versie en de lijst met nodes met hun online-status.
  • DirectAdmin: de versie van het paneel, het aantal accounts, hoeveel commando's je login key mag draaien, en of de verbinding versleuteld is. Dat laatste kan alleen je agent vaststellen.
  • Webmin: of de Virtualmin-module antwoordt, hoeveel hostingaccounts en plannen er zijn, en of het certificaat klopt met de fingerprint die je invulde.
  • Pterodactyl: het aantal nodes en gameservers, en of de client-sleutel werkt. Zonder die sleutel is er geen aan en uit en geen console, en dat wil je weten vóór je eerste startknop en niet erna.
Een test op een integratie waarvan de inloggegevens nooit zijn aangenomen, toont de reden waarom ze geweigerd werden in plaats van te draaien, want dat is het antwoord waar je naar zocht.

Uitschakelen en verwijderen

Uitschakelen is de veilige tussenstap: de agent krijgt geen opdrachten meer voor die integratie en alles blijft staan waar het staat. Weer inschakelen zet hem terug op actief als de inloggegevens eerder aangenomen waren, en anders terug op wacht-op-inloggegevens, want of ze nog werken kan alleen een test je vertellen.

Een integratie met servers eronder kan niet verwijderd worden, en de weigering noemt het aantal. Die servers hangen aan de integratie en zouden stilletjes verdwijnen, licentietelling incluis.

Als er iets misgaat

De agent meldt een code met parameters, geen zin, zodat het paneel je de reden in je eigen taal kan tonen. Waar de andere kant zelf iets zei – een HTTP-body van je hypervisor, een fout uit je paneel – staat dat er onvertaald onder geciteerd, want het is een citaat.

Er is een tweede kanaal voor het geval het-lukte-maar. Een paneel dat over een onversleutelde verbinding werkt is geen fout, en het is ook geen status, dus het verschijnt als waarschuwing op het tabblad Overzicht zolang je agent het blijft melden.