FAQ

Ofte stilte spørsmål

Praktiske korte guider for tjenesteoppsett, tilgang og vanlige kundehandlinger.

> Lag en offentlig SSH-nøkkel i terminalen

Lag en offentlig SSH-nøkkel for tilgang, og del bare den offentlige delen.
faq/generate-public-ssh-key-no

Bruk bare den offentlige nøkkelen

SSH bruker et nøkkelpar. Lim bare inn den offentlige nøkkelen, vanligvis .pub-filen, i tjenesteinnstillingene. Den private nøkkelen blir på enheten din.

Steg i terminalen

  1. Åpne Terminal, Windows Terminal eller PowerShell.
  2. Kjør: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Godta standard plassering eller velg en trygg sti.
  4. Vis den offentlige nøkkelen med: cat ~/.ssh/id_ed25519.pub.
  5. I Windows PowerShell bruker du: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopier hele ssh-ed25519-linjen til feltet SSH public key.

Sjekk før du limer inn

Ikke kopier den private nøkkelen. Hvis du setter en passphrase, må den lagres trygt.

> Lag en SSH-nøkkel grafisk i Windows

Bruk PuTTYgen i Windows og kopier bare den offentlige nøkkelen.
faq/create-ssh-key-windows-gui-no

Bare den offentlige delen

PuTTYgen lager både offentlig og privat nøkkel. Legg bare den offentlige nøkkelen inn i Cli>_, og behold den private lokalt.

Steg i Windows

  1. Åpne PuTTYgen.
  2. Velg EdDSA / Ed25519 når det er tilgjengelig.
  3. Bruk RSA 4096 bare som reserve.
  4. Klikk Generate og flytt musen til nøkkelen er opprettet.
  5. Lagre den private nøkkelen på datamaskinen din.
  6. Kopier teksten for den offentlige nøkkelen til SSH public key-feltet.

Ikke del hemmelige data

Ikke send .ppk-filer, private nøkler, passphrase, passord eller tokens til support eller skjemaer.

> Koble til eget domene

Bekreft autoritativ DNS, nøyaktig hostname, apex eller subdomene, støttet record-type og gamle konflikter.
faq/koble-til-eget-domene

Det nøyaktige vertsnavnet styrer valgene

example.com og app.example.com kan kreve ulike DNS-typer og ha ulike begrensninger hos registrar eller DNS-leverandør. Finn også ut hvor de autoritative DNS-recordene faktisk redigeres.

Før DNS endres

  1. Finn eksisterende A/AAAA, CNAME, ALIAS, ANAME eller redirect for samme hostname.
  2. Fjern eller juster konflikter før ny verdi legges inn.
  3. Bruk record-typen tjenesten anbefaler for hostname-typen.
  4. Vent på DNS-propagasjon og sertifikatkontroll før gammel løsning slås av.

Planlegg tilbakerulling

Noter gamle DNS-verdier før endring og behold gammel løsning til sertifikat og ny rute fungerer. Da kan du raskt gå tilbake ved feil.

> Overfor en DNS-sone

A/AAAA peker til adresser, CNAME lager alias, MX ruter e-post og TXT brukes til verifisering, SPF, DKIM og DMARC.
faq/overfor-en-dns-sone

Ikke bland recordtyper tilfeldig

A og AAAA peker til IP-adresser, CNAME brukes for tillatte subdomenealias, MX for e-post, TXT for verifisering og mail-policy, og CAA for sertifikatmyndigheter. Feil CAA kan stoppe sertifikatutstedelse.

Mailrelaterte records

  1. SPF legges der e-postleverandøren ber om det.
  2. DKIM legges under leverandørens selector.
  3. DMARC ligger vanligvis under _dmarc.
  4. Ikke legg CNAME på et hostname som også må ha andre records hvis DNS-reglene forbyr det.

Unngå konflikt på samme navn

Et CNAME-navn kan vanligvis ikke ha andre records samtidig. Sjekk at web, e-post og verifisering ikke konkurrerer om samme hostname.

> Kontoregistrering og første innlogging

Opprett én kundekonto for bestillinger, faktura og drift, med en e-post teamet ikke mister tilgang til.
faq/account-registration-and-login

Bruk en varig arbeidsadresse

Kontoen samler bestillinger, fakturadata, domener, tjenester og supportdialog. Velg en arbeidsadresse teamet kan beholde ved ferie eller personbytte, ikke en privat postkasse som bare én person kontrollerer.

Før første betalte ordre

  1. Registrer deg med arbeidsadressen.
  2. Fullfør e-postbekreftelse hvis den blir bedt om.
  3. Legg inn fakturainformasjon før du bestiller betalte tjenester.
  4. Aktiver tofaktorautentisering når den er tilgjengelig.

Unngå å miste tilgang

Avtal hvem som eier e-post, passordhåndtering og gjenoppretting. Da beholder teamet tilgang til faktura, ordre og tjenestestyring selv om en person slutter.

> Slik fungerer forhåndsbetalt kreditt

Kreditten viser saldo, estimert kjøretid, daglig kostnad per aktiv tjeneste og risiko for suspensjon eller sletting.
faq/prepaid-credit-how-it-works

Kreditt brukes mens tjenester kjører

Aktive forhåndsbetalte tjenester trekker kreditt over tid ut fra CPU, RAM, lagring og valgte tillegg. Den synlige saldoen og estimert kjøretid hjelper deg å fylle på før en tjeneste stoppes.

Unngå uventet stopp

  1. Følg saldo og kjøretidsindikator i kundeområdet.
  2. Sjekk vist pris og daglig kostnad før ordre eller endring bekreftes.
  3. Reager på lav saldo, suspensjonsvarsel og synlig slettefrist.
  4. Fyll på i god tid før saldoen er tom.

Når saldoen blir lav

Ved tom saldo kan tjenester bli suspendert og vise en slettefrist. Fyll på eller kontakt support før fristen hvis du vil unngå at data fjernes senere.

> Månedsestimat, årsestimat og daglig forbruk

Måned og år er sammenligningsverdier; faktisk forhåndsbetalt forbruk skjer daglig etter at ordre eller endring er brukt.
faq/billing-periods-and-credit-burn

Estimat er ikke en kalenderfaktura

Månedsprisen bruker 31 dager og årsestimatet 372 dager for sammenligning. Forhåndsbetalte tjenester trekker kreditt etter aktiv tid og bekreftet konfigurasjon, først etter bekreftelse, eventuell betaling og anvendt endring.

Når prisen endres

  1. Sammenlign daglig kostnad før og etter endringen.
  2. Vurder effekten av mer CPU, RAM, disk eller betalte valg.
  3. Vent til endringen er anvendt før du regner med ny kostnad.
  4. Lagre ordrebekreftelser, faktura og synlig kreditthistorikk.

Bruk daglig kostnad som styring

Se på daglig kostnad når du planlegger saldo. Etter en endring bør du først sjekke at den er anvendt før du beregner hvor lenge kreditten varer.

> Ordrestatus etter betaling

En ordre kan vente på bekreftelse fra betalingsleverandøren; ikke opprett duplikat før første ordre er klart utløpt eller feilet.
faq/order-status-and-payment-confirmation

Pending betyr ikke alltid feil

Etter betaling kan ordren ligge og vente på bekreftelse fra betalingsleverandøren. En duplikatordre før første ordre er tydelig kansellert eller utløpt kan gjøre avstemming vanskeligere.

Etter at betalingen er fullført

  1. Gå tilbake til Cli>_ fra betalingssiden.
  2. Kontroller ordrestatus i kontoen.
  3. Vent på leverandørbekreftelse hvis status fortsatt er pending.
  4. Kontakt support med ordrenummer og eventuell betalingsreferanse hvis status ikke endres.

Ikke lag duplikater

Selv om betalingsvinduet lukkes eller du går tilbake, kan første ordre fortsatt bli bekreftet. Noter ordrenummeret og vent til statusen er avklart før du bestiller på nytt.

> Informasjon som trengs for oppsett

Forbered tjenestenavn, domene, DNS-plan, admin-e-post, ressurser og offentlig SSH-nøkkel, men ikke hemmeligheter.
faq/service-setup-information-needed

Presise offentlige verdier sparer tid

Oppsettfelter er ment for tjenestenavn, domener, DNS-valg, lagring, CPU, RAM, admin-e-post og offentlige SSH-nøkler. Passord, private nøkler, tokens og databaseeksporter hører ikke hjemme i skjemaet.

Klargjør før bestilling

  1. Velg et tjenestenavn teamet kjenner igjen.
  2. Bestem om du bruker eget domene eller midlertidig vertsnavn.
  3. Lag offentlig SSH-nøkkel hvis tjenesten krever det.
  4. Sjekk ressursbehov mot applikasjonen du skal kjøre.

Hold hemmeligheter utenfor skjema

Offentlig SSH-nøkkel kan deles, men privatnøkkel og passord skal ikke inn i ordre eller supportmelding. Del offentlige verdier, valgte ressurser og synlige feil.

> Endre CPU, RAM, disk eller retensjon etter ordre

Endre eksisterende tjeneste fra tjenestedetaljen og vurder ny pris, daglig kredittforbruk, restart og nedetidsrisiko.
faq/change-service-resources-after-order

Endre tjenesten, ikke bestill en ny kopi

Hvis tjenesten allerede kjører, gjør ressursendringen fra dens detaljside. En ny ordre kan opprette en ekstra tjeneste. Endringen gjelder først etter bekreftelse, eventuell betaling og anvendt konfigurasjon.

Før du bekrefter

  1. Se nåværende CPU, RAM, disk, backup-retensjon og Offsite Archive-retensjon.
  2. Kontroller ny pris og daglig kredittforbruk.
  3. Les varsler om restart, vedlikehold eller nedetid.
  4. Eksporter viktige data før en risikabel endring.

Vurder praktisk påvirkning

CPU- og RAM-endringer kan kreve kort restart, mens disk og retensjon kan ta mer tid. Bekreft endringen når du vet om den påvirker arbeidstid eller brukere.

> Kansellering og datalagring

En ferdig opprettet tjeneste suspenderes først, viser synlig slettefrist og kan deretter ryddes permanent etter livssyklusen.
faq/cancel-service-and-data-retention

Kansellering er ikke alltid øyeblikkelig sletting

En ferdig opprettet tjeneste blir vanligvis suspendert først og viser en konfigurerbar synlig slettefrist. Etter fristen kan permanent opprydding skje. Ubetalte ordre som ikke er satt opp ennå, kan ha en annen dataflyt.

Før du kansellerer

  1. Lag egen eksport av data du må beholde.
  2. Les suspensjonsvarsel og synlig slettefrist.
  3. Ikke forveksle backup eller Offsite Archive med tjenestens slettefrist.
  4. Kontakt support før fristen hvis du er usikker.

Ta ut data først

Eksporter filer, database eller appdata du må beholde før kansellering. Backup og Offsite Archive er ikke en garanti for permanent lagring etter at tjenesten fjernes.

> Backup og gjenopprettingsforespørsler

Backup er for operativ gjenoppretting, ikke erstatning for egen eksport; restore kan overskrive nyere data.
faq/backups-and-restore-requests

Backup er ikke arkiv eller eksport

Retensjon avhenger av produkt og valg. Backup hjelper ved feil og driftsgjenoppretting, men erstatter ikke egen eksport, revisjonsarkiv eller Offsite Archive. En restore kan rulle nyere endringer tilbake.

Skriv en presis restore-forespørsel

  1. Oppgi tjenestenavn og ordrenummer.
  2. Beskriv omtrent hvilket tidspunkt du vil tilbake til.
  3. Si om hele tjenesten eller en bestemt del skal gjenopprettes hvis støttet.
  4. Legg ved synlig feil eller kontekst uten passord, tokens eller private nøkler.

Avklar restore-omfang

En restore kan gjelde hele tjenesten eller bare en del, og kan erstatte nyere endringer. Oppgi ønsket tidspunkt og hva du forventer skal komme tilbake.

> Hva Offsite Archive brukes til

Offsite Archive lagrer eksterne arkivkopier separat fra korte driftsbackuper og tjenestens sletteflyt.
faq/offsite-archive-purpose

Arkiv utenfor normal drift

Offsite Archive er for fjernlagrede arkivkopier, eksportsett og eldre materiale. Det er ikke en live applikasjonsdisk, ikke det samme som korte backuper og ikke en garanti for å forlenge tjenestens slettefrist.

Vurder retensjon og volum

  1. Velg retensjonsdager etter krav eller gjenopprettingsmål.
  2. Tenk MB-dager som lagrede MB ganger dager lagret.
  3. Prisen vises som EUR/GB/måned og avrundes til hele cent.
  4. Se over kostnaden når datamengde eller retensjon vokser.

Skilt fra live drift

Offsite Archive er ikke et sted applikasjonen skriver til i sanntid. Bruk det for kopier som skal ligge lenger, og vurder pris ut fra datamengde og retensjonsdager.

> Velge CPU, RAM og disk for VPS

Dimensjoner etter applikasjon, database, cache, logger og vekst; OOM og swap tyder ofte på for lite RAM.
faq/vps-cpu-ram-and-disk-sizing

Arbeidslasten bestemmer størrelsen

En statisk side trenger ofte langt mindre enn en database, søk, Java-applikasjon eller build-worker. Regn inn minnebruk, cache, logger, opplastinger, databasevekst og rom for trafikkøkning.

Tegn på at planen er for liten

  1. Øk RAM ved OOM, out of memory, process killed eller mye swap.
  2. Øk CPU ved vedvarende beregning, komprimering, builds eller travle workere.
  3. Øk disk før filsystem, logger eller database blir fulle.
  4. Sjekk etter endring om den opprinnelige feilen faktisk forsvant.

Start nøkternt og følg med

Du kan starte med en moderat størrelse, men følg med på logger, databasevekst, opplastinger og minnebruk. Øk før tjenesten treffer harde grenser.

> Når offentlig IP gir mening for VPS

Dedikert offentlig IP hjelper ved allowlist, inbound tilgang, stabil outbound-kilde eller tjenester bundet til adresse.
faq/vps-public-ip-options

Avklar trafikkretningen først

Offentlig IP er ikke nødvendig for alle tjenester. Den er nyttig når partnere, leverandører eller brannmurer krever stabil adresse for inbound tilgang, outbound kilde eller begge deler.

Spørsmål før IP bestilles

  1. Spør om allowlist gjelder inbound, outbound eller begge retninger.
  2. Bruk DNS-navn i stedet for talladresser når mulig.
  3. Åpne bare portene applikasjonen faktisk trenger.
  4. Del allowlist-kravet med support før produksjonstilgang endres.

Når direkte vei trengs

Dedikert offentlig IP velges når eksterne systemer må nå VPS-en direkte, eller når en partner krever fast outbound-kilde. Hvis delt SSH dekker behovet, er egen IP ikke obligatorisk.

> Delt SSH-tilgang til VPS

Uten egen offentlig IP kobles VPS via delt SSH-adresse med høy port; med offentlig IP kan direkte SSH også være tilgjengelig.
faq/shared-ssh-access-for-vps

Høy port peker til riktig VPS

Flere VPS-er kan dele samme offentlige SSH-vert. Derfor får hver tjeneste en egen høy port, og porten er en del av rutingen til akkurat din VPS. Uten den vet ikke den delte SSH-adressen hvilken tjeneste som skal nås.

Koble til riktig SSH-adresse

  1. For delt SSH kopierer du SSH-brukernavn, offentlig SSH-vert og høy port fra tjenesten.
  2. Bruk ssh -p <port> <username>@<public-host>.
  3. Hvis tjenesten har dedikert offentlig IP, kan den også vise direkte SSH på denne IP-en eller DNS-navnet.
  4. Bruk privatnøkkelen lokalt; support trenger bare host, port, username og synlig feil.

Delt SSH mot direkte SSH

Delt SSH bruker samme offentlige vert for flere VPS-er, derfor identifiserer den høye porten riktig VPS. Med dedikert offentlig IP kan tjenesten også tilby direkte SSH til IP-en eller DNS-navnet, ofte på vanlig SSH-port.

> Sjekkliste før eget domene kobles til

Bekreft autoritativ DNS, nøyaktig hostname, apex eller subdomene, støttet record-type og gamle konflikter.
faq/custom-domain-readiness-checklist

Det nøyaktige vertsnavnet styrer valgene

example.com og app.example.com kan kreve ulike DNS-typer og ha ulike begrensninger hos registrar eller DNS-leverandør. Finn også ut hvor de autoritative DNS-recordene faktisk redigeres.

Før DNS endres

  1. Finn eksisterende A/AAAA, CNAME, ALIAS, ANAME eller redirect for samme hostname.
  2. Fjern eller juster konflikter før ny verdi legges inn.
  3. Bruk record-typen tjenesten anbefaler for hostname-typen.
  4. Vent på DNS-propagasjon og sertifikatkontroll før gammel løsning slås av.

Planlegg tilbakerulling

Noter gamle DNS-verdier før endring og behold gammel løsning til sertifikat og ny rute fungerer. Da kan du raskt gå tilbake ved feil.

> DNS-recordtyper for tjenester

A/AAAA peker til adresser, CNAME lager alias, MX ruter e-post og TXT brukes til verifisering, SPF, DKIM og DMARC.
faq/dns-record-types-for-services

Ikke bland recordtyper tilfeldig

A og AAAA peker til IP-adresser, CNAME brukes for tillatte subdomenealias, MX for e-post, TXT for verifisering og mail-policy, og CAA for sertifikatmyndigheter. Feil CAA kan stoppe sertifikatutstedelse.

Mailrelaterte records

  1. SPF legges der e-postleverandøren ber om det.
  2. DKIM legges under leverandørens selector.
  3. DMARC ligger vanligvis under _dmarc.
  4. Ikke legg CNAME på et hostname som også må ha andre records hvis DNS-reglene forbyr det.

Unngå konflikt på samme navn

Et CNAME-navn kan vanligvis ikke ha andre records samtidig. Sjekk at web, e-post og verifisering ikke konkurrerer om samme hostname.

> DNS-propagasjon og TTL

TTL og resolver-cache avgjør hvor lenge gamle svar kan leve side om side med nye DNS-svar.
faq/dns-propagation-and-ttl

Propagasjon er cache-atferd

Når autoritativ DNS endres, kan resolvere fortsatt returnere gamle svar til TTL utløper. Derfor kan ulike nett, land eller resolvere vise forskjellig resultat en stund.

Planlegg en ryddig overgang

  1. Senk TTL før planlagt bytte hvis leverandøren tillater det.
  2. Gjør endringen én gang og unngå tilfeldige omskrivinger mens cache utløper.
  3. Test fra flere resolvere hvis svarene spriker.
  4. Noter gammel verdi, ny verdi, TTL og tidspunkt for endringen.

Sjekk fra flere steder

Rett etter endring kan én resolver vise gammel verdi og en annen ny. Sammenlign autoritativ DNS, et annet nett og offentlig resolver før du antar feil.

> Planlegging av Nextcloud-lagring

Regn med brukerfiler, delte mapper, versjoner, papirkurv, forhåndsvisninger, synkronisering og teamvekst.
faq/nextcloud-storage-planning

Nextcloud vokser utenfor synlige filer

Kapasitet brukes av brukerfiler, delte mapper, slettede filer, versjonshistorikk, previews, thumbnails, synkklienter og importer. Nær grensen kan opplasting og synkronisering feile.

Før kapasitet bestilles

  1. Summer dagens brukerdata og fellesmapper.
  2. Legg til margin for versjoner, papirkurv, previews og sync-overhead.
  3. Ta høyde for store importer, nye team og forventet vekst.
  4. Øk lagring før brukerne treffer grensen.

Margin hindrer sync-feil

Når lagringen nesten er full, kan opplasting, synkronisering, previews og versjoner feile. Legg inn kapasitet før nye brukere eller store importer.

> Migrere repositories til Gitea

Planlegg flytting av Git-repositories sammen med LFS, submodules, rettigheter, deploy keys, webhooks og CI/CD.
faq/gitea-repository-migration

Migrering er mer enn git clone

Historikk er bare én del. Eiere, team, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks og CI/CD-integrasjoner må flyttes eller gjenopprettes.

Kontroll før cutover

  1. List repositories, eiere, grupper og automasjonskontoer.
  2. Sjekk Git LFS, submodules, branch protections og tag protections.
  3. Test clone, push, Git LFS, submodules og CI etter flytting.
  4. Roter eller fjern gamle tokens uten å dele tokenverdier.

Flytt rettigheter og automasjon

Historikk alene er ikke nok. Test deploy keys, webhooks, branch protection og CI før gammel plattform settes skrivebeskyttet eller stenges.

> Avsenderdomene for Listmonk

Klargjør senderdomene eller subdomene, From-identitet, SPF, DKIM, DMARC, bounce og avmelding før kampanje.
faq/listmonk-sender-domain-basics

Levering starter med domenet

Nyhetsbrev leveres bedre når avsenderdomenet har riktige DNS-records og tydelig From-identitet. SPF, DKIM og DMARC må samsvare med domenet eller subdomenet du sender fra.

Før første utsending

  1. Velg senderdomene eller subdomene og From-navn.
  2. Publiser verifisering, SPF, DKIM-selector og DMARC.
  3. Test leveranse, bounce eller Return-Path og lenker.
  4. Sjekk avmelding og List-Unsubscribe før produksjonskampanje.

Test med lavt volum

Send til interne eller få mottakere først. Kontroller spam-score, lenker, avmelding og bounce før første store kampanje.

> Kjøremiljø for Classic Hosting

Classic Hosting kan bruke automatisk eller manuelt kjøremiljø; PHP-valg og ressurser må passe applikasjonen.
faq/classic-hosting-runtime-settings

Auto er nyttig, men ikke alltid riktig

Automatisk kjøremiljø hjelper for gjenkjente PHP-, Node.js-, Java-, Python-, .NET-, Go- og Ruby-prosjekter. Manuelt kjøremiljø passer når du vil styre Nginx, Apache, FrankenPHP eller språkvalg mer presist. PHP-valg gjelder bare der valgt kjøremiljø støtter det.

Innstillinger før publisering

  1. Velg automatisk eller manuelt kjøremiljø etter rammeverk og byggemåte.
  2. Bruk PHP 8.2, 8.3 eller 8.4 bare i støttede PHP-scenarier.
  3. Sett CPU, RAM, lagring, backup-retensjon og Offsite Archive-retensjon.
  4. Test opplastinger, cache, logger og synlige appfeil etter publisering.

Velg etter applikasjonen

Auto er praktisk, men manuell innstilling kan være tryggere når du kjenner startkommando, public directory, vedvarende filer eller nødvendige PHP-utvidelser.

> Informasjon du trygt kan dele med support

Ordrenummer, tjenestenavn, domener, tidspunkter, offentlig host/port og synlige feil hjelper; hemmeligheter skal ikke sendes.
faq/support-safe-information-to-share

En god sak har kontekst, ikke hemmeligheter

Support kan reagere raskere med ordrenummer, synlig tjenestenavn, domene, offentlig host eller port, tidspunkt, hva som ble endret og eksakt synlig feilmelding.

Sikre detaljer i meldingen

  1. Ta med ordre, tjeneste, domene, tidspunkt og trinnet der feilen oppsto.
  2. For hosting: runtime, PHP eller språk, CPU, RAM, disk, opplastinger, cache og logger uten hemmelige verdier.
  3. Masker skjermbilder før de sendes.
  4. Send aldri passord, private nøkler, API-tokens, seed phrases, databaseeksporter eller fulle logger med sensitive verdier.

Beskriv reproduksjon kort

Skriv hva du gjorde, forventet resultat, faktisk feilmelding og tidspunkt. Masker hemmeligheter og del bare offentlige verdier.