Vanlige spørsmål

Vanlige spørsmål

Praktiske, korte veiledninger for oppsett av tjenester, tilgang og vanlige kundehåndteringsoppgaver.

> Hvordan fungerer Cli>_ kredittsystemet?

Én felles forhåndsbetalt saldo finansierer alle kvalifiserte tjenester og brukes bare mens de er aktive.
faq/prepaid-credit-how-it-works

Cli>_ kontoen din har én felles forhåndsbetalt kredittsaldo. Kvalifiserte nye kunder kan først kreve Starter Credit etter at de har fullført den obligatoriske konto- og misbruksverifiseringen. Aktive kvalifiserte tjenester bruker saldoen over tid. Månedsestimatet benytter 31 dager, og en ny tjeneste kan bare starte hvis saldoen dekker minst 7 dager. Et rødt varsel vises når estimert driftstid faller under 7 dager; ellers vises et oransje varsel når den faller under 14 dager.

Når saldoen er tom, suspenderes tjenesten etter 7 dager, slutter å bruke kreditt, og oppbevarings- og slettingsfristen på 7 dager starter. Før den viste fristen kan den startes igjen med nok kreditt. Kansellering av en klargjort tjeneste suspenderer den også og starter samme frist. En ventende, ikke-klargjort tjeneste kan deaktiveres umiddelbart. Etter fristen starter deaktivering og fjerning av den klargjorte tjenesten. Force delete deaktiverer tjenesten umiddelbart, hopper over oppbevaringen og starter fjerning fra aktiv runtime; fullføring følger deployment- og GitOps-behandlingen. Sikkerhetskopier og Offsite Archive har separate regler for oppbevaring.

Eksempel med OpenCode til 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR per dag. Etter 10 hele dager er omtrent 3,19 EUR brukt. Hvis startsaldoen var nøyaktig 9,90 EUR uten andre tjenester, gjenstår omtrent 6,71 EUR. Forbruket stopper etter deaktivering.

Eksemplet er bare veiledende. Gjeldende priser som vises i Cli>_ gjelder alltid.

> Slik genererer du en offentlig SSH-nøkkel via kommandolinjen

Opprett en offentlig SSH-nøkkel for sikker tilgang til din virtuelle server. Del kun den offentlige nøkkelen med Cli>_; behold den private nøkkelen på din egen enhet.
faq/generate-public-ssh-key-no

Den offentlige nøkkelen deles, den private nøkkelen forblir hos deg

Lim kun inn den offentlige SSH-nøkkelen i bestillingen eller tjenesteoppsettet. Den private nøkkelen lagres på datamaskinen din og sendes ikke til support eller legges inn i et webformular.

Fremgangsmåte

  1. Åpne et terminalvindu på datamaskinen din.
  2. Kjør kommandoen: ssh-keygen -t ed25519 -C "din-e-post@eksempel.com".
  3. Bekreft hvor filen skal lagres, eller velg en egen plassering. Del aldri din private nøkkel med noen.
  4. Vis den offentlige nøkkelen ved hjelp av kommandoen: cat ~/.ssh/id_ed25519.pub.
  5. Kopier hele linjen som starter med ssh-ed25519, og lim den inn i feltet for SSH-offentlig nøkkel under bestilling eller tjenesteoppsett.
  6. Kopier hele linjen som starter med ssh-ed25519, og lim den inn i feltet for SSH-offentlig nøkkel.

Sjekk før du limer inn

  1. Åpne PowerShell eller Windows Terminal.
  2. Kjør kommandoen: ssh-keygen -t ed25519 -C "din-epost@example.com".
  3. Trykk Enter for å lagre nøkkelen til C:\Users\brukernavn\.ssh\id_ed25519, eller angi en egen sti.
  4. Hvis Windows ber om en passordfrase, bruk en du kan lagre trygt, eller trykk Enter for å hoppe over den ved enkel oppsett.
  5. Vis den offentlige nøkkelen ved hjelp av kommandoen: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopier kun hele linjen som starter med ssh-ed25519. Ikke kopier eller last opp filen som inneholder den private nøkkelen.
> Hvordan du lager en SSH-nøkkel grafisk i Windows

En visuell guide for å opprette et SSH-nøkkelpar i Windows uten bruk av kommandolinjen.
faq/create-ssh-key-windows-gui-no

Bruk et Windows-verktøy og lim inn kun den offentlige nøkkelen

Du kan generere et SSH-nøkkelpar visuelt med en Windows SSH-klient som PuTTYgen. Cli>_ trenger bare den offentlige nøkkelen. Behold den private nøkkelen på datamaskinen din og last den aldri opp via et webformular.

Fremgangsmåte

  1. Installer PuTTY eller åpne PuTTYgen hvis den allerede er installert.
  2. Velg EdDSA/Ed25519 hvis tilgjengelig, ellers velg RSA 4096.
  3. Klikk på Generer og beveg musen over det tomme området til nøkkelen vises.
  4. Legg til en passordfrase hvis du ønsker ekstra lokal beskyttelse for den private nøkkelen.
  5. Lagre den private nøkkelen på datamaskinen din og hold den hemmelig.
  6. Kopier teksten til den offentlige nøkkelen og lim den inn i feltet for SSH-offentlig nøkkel i Cli>_.

Del ikke sensitive data

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

> Ta med deg ditt eget domene

Lær hvordan du peker din egen domene eller subdomene mot en CLIopen-tjeneste før du aktiverer funksjonen for å bruke ditt eget domene.
faq/koble-til-eget-domene

Hva denne innstillingen gjør

Med "Bruk ditt eget domene" kan tjenesten din svare på ditt eget vertsnavn, for eksempel app.example.com, i stedet for å bruke det genererte vertsnavnet *.co.cliopen.cloud. DNS-innstillingene må peke til CLIopen før vertsnavnet kan brukes trygt av tjenesten.

Før du starter

  1. Velg det nøyaktige vertsnavnet du ønsker å bruke, for eksempel app.example.com. Det enkleste er å bruke et subdomene.
  2. Åpne DNS-administrasjonen hos din domeneregistrator eller DNS-leverandør.
  3. Fjern eventuelle konflikterende A-, AAAA-, CNAME-, ALIAS- eller omdirigeringsposter for samme vertsnavn.
  4. La det automatisk genererte CLIopen-vertsnavnet være aktivt inntil ditt egne vertsnavn er verifisert og fungerer som forventet.

Anbefalte DNS-innstillinger for en underdomene

Opprett DNS-poster for det nøyaktige vertsnavnet du skal angi i CLIopen. For app.example.com er DNS-etiketten app. Pek den mot CLIopen ingress-adressene du får fra CLIopen-support eller i tjenestedokumentasjonen. Hvis leverandøren din spør etter en posttype, bruk en 'A'-post for IPv4 og en 'AAAA'-post for IPv6 når disse adressene er oppgitt.

Eksempel:

app.example.com.  A     <CLIopen IPv4-adresse>
app.example.com.  AAAA  <CLIopen IPv6-adresse, hvis tilgjengelig>

Når CLIopen oppgir et CNAME-mål

Noen tjenester gir deg et generert vertsnavn, for eksempel service.customer.co.cliopen.cloud. Hvis instruksjonene for tjenesten din spesifikt krever en CNAME, opprett en DNS-oppføring som app.example.com CNAME service.customer.co.cliopen.cloud. Bruk kun CNAME for underdomener, ikke for toppnivådomenet, med mindre din DNS-leverandør støtter ALIAS eller ANAME flattening.

Bruke toppnivådomenet

For et toppenivådomene som example.com, tillater de fleste DNS-leverandører ikke en standard CNAME-oppføring. Bruk A/AAAA-poster som peker til CLIopen ingress-adressene, eller bruk leverandørens ALIAS/ANAME-funksjon hvis CLIopen har oppgitt et mål-hostnavn.

Delegering av hele underdomenet

Hvis du ønsker at CLIopen skal administrere poster under en underdomene, for eksempel apps.example.com, oppretter du NS-poster for dette underdomenet som peker til CLIopens navneservere. Endre ikke navneserverne for hele domenet med mindre du bevisst ønsker at CLIopen (eller en annen DNS-tjeneste) skal administrere alle poster.

Kontrolliste

  1. Vent på at DNS-endringene skal forplante seg. Små endringer vises ofte innen få minutter, men noen leverandører lagrer data lenger.
  2. Sjekk at vertsnavnet peker til CLIopen-målet og ikke til en tidligere leverandør.
  3. Skriv inn nøyaktig vertsnavn i feltet "Bruk ditt eget domene", uten `https://` og uten sti.
  4. Etter oppdateringen, test `https://app.example.com` i nettleseren din.
  5. Behold gamle DNS-oppføringer kun hvis de ikke er i konflikt med det nye vertsnavnet.
> Hvordan overføre en DNS-sone til CLIopen

Deleger et domene til ns1.cliopen.com og ns2.cliopen.com, slik at CLIopen kan publisere oppføringer for hele sonen.
faq/overfor-en-dns-sone

Hva betyr soneoverføring her?

Når det gjelder DNS-overføring for kunder, innebærer dette å endre de autoritative navneserverne hos din domeneregistrator. Etter at du har delegert til CLIopen, publiseres DNS-oppføringer som er lagt til i CLIopen fra våre autoritative navneservere.

Før du endrer navneservere

  1. Kopier eksisterende DNS-oppføringer som du fortsatt trenger, for eksempel nettsted, e-post, verifisering, SPF, DKIM, DMARC og tjenesteoppføringer.
  2. Legg til sonen i CLIopen DNS. Hvis delegasjonen ikke er klar ennå, lagrer CLIopen den, men aktiverer den ikke for kundene før valideringen er fullført.
  3. Opprett de nødvendige oppføringene i CLIopen DNS før du bytter navneservere, hvis mulig.
  4. Vær oppmerksom på at feil CAA-innstillinger kan hindre utstedelse av sertifikater.

Deleger sone

  1. Åpne domeneinnstillingene hos registeren din, for eksempel example.com.
  2. Finn innstillinger for navneservere, DNS-delegasjon eller autoritativ DNS.
  3. Erstatt de eksisterende navneserverne med ns1.cliopen.com og ns2.cliopen.com.
  4. Lagre endringen og vent på at den spres til registeret og resolverne.

Validering

Gå tilbake til CLIopen DNS og klikk på 'Bekreft delegasjon'. Når de offentlige NS-oppføringene viser ns1.cliopen.com og ns2.cliopen.com, vil sonen bli satt i kø for synkronisering, og oppføringene blir aktive fra CLIopen.

> Opprett konto og logg inn

Opprett én kundekonto for bestillinger, fakturering og administrasjon. Bruk en e-postadresse som teamet ditt kan ha tilgang til.
faq/account-registration-and-login

En konto for bestillinger og administrasjon

Bruk kontoen som et langsiktig sted for bestillinger, fakturainformasjon, tjenester, domener og kommunikasjon med support. Det er best å bruke en firmamailadresse som teamet har tilgang til, selv etter personalendringer.

Før din første bestilling

  1. Registrer deg med din arbeidsepostadresse.
  2. Bekreft e-posten hvis du blir bedt om det.
  3. Fyll inn fakturainformasjon før du bestiller betalte tjenester.
  4. Aktiver tofaktorautentisering så snart den er tilgjengelig.

Tilgang for teamet

Ikke send passord til kolleger via chat eller e-post. Hvis flere trenger tilgang, bruk en intern passordbehandler eller følg anbefalte teamrutiner; support trenger ikke passordet ditt eller påloggingsnøkkelen.

> Estimert månedlig forbruk, estimert årlig forbruk og faktisk daglig forbruk

Månedlige og årlige priser brukes for sammenligning; ved forhåndsbetalte tjenester bestemmes det faktiske forbruket daglig etter at en bestilling eller endring er bekreftet.
faq/billing-periods-and-credit-burn

Estimater er ikke en faktureringskalender

Bruk månedlige estimater som en sammenligning for 31 dager, og årlige estimater som en sammenligning for 372 dager. Det faktiske forbruket av kreditt for forhåndsbetalte tjenester skjer basert på den aktive brukstiden til tjenesten og den bekreftede konfigurasjonen.

Hva du bør sjekke når prisen endres

  1. Sammenlign den daglige bruk før og etter endringen.
  2. Høyere CPU, RAM, disk eller tilleggstjenester kan føre til høyere daglig forbruk.
  3. Endringen trer i kraft først etter bekreftelse, eventuell betaling og aktivering.
  4. Lagre ordrebekreftelser og kredithistorikk for regnskapsføringen.

Fokuser på den spesifikke perioden ved feilsøking

For at support skal kunne hjelpe deg, trenger de ordrenummer, tjenestenavn og datoer du ønsker å sjekke. Ikke send bankdetaljer, komplette kontoutskrifter eller skjermbilder som inneholder uønskede personopplysninger.

> Status for ordre etter betaling

Bestillingen kan vente litt på bekreftelse fra leverandøren før den behandles. Ikke opprett en kopi av bestillingen før den første er tydelig kansellert eller utløpt.
faq/order-status-and-payment-confirmation

'Venter' betyr ikke nødvendigvis feil

Etter at du har fullført betalingen, kan bestillingen din fortsatt vente på bekreftelse fra betalingsleverandøren. Inntil status er tydelig som mislykket eller utløpt, kan en ny, duplisert bestilling unødvendig komplisere avstemmingen.

Hva du skal gjøre etter betaling

  1. Etter at betalingen er fullført, gå tilbake til Cli>_.
  2. Sjekk ordrestatusen i kontoen din.
  3. Hvis bestillingen fortsatt venter, gi leverandøren tid til å bekrefte.
  4. Hvis du har problemer, send ordrenummeret og referansen for betalingen til kundestøtten (hvis du finner den).

Hva du ikke skal sende inn

Kundestøtten trenger ikke informasjon fra kredittkortet ditt, passord eller hele bankbekreftelsen. Oppgi ordrenummer, tidspunkt for betaling, synlig status og et skjermbilde der sensitive opplysninger er skjult, hvis det vises en feil.

> Informasjon som fremskynder konfigurasjonen av tjenesten

Forbered tjenestnavn, domene, lagringsplass, e-postadresse for tilgang og offentlig SSH-nøkkel; legg ikke inn sensitive opplysninger i skjemaet.
faq/service-setup-information-needed

Nøyaktige opplysninger sparer tid

Bruk bestillingsskjemaene for offentlige eller usensitive verdier: tjenestenavn, domene, DNS-innstillinger, lagringsplass, CPU, RAM, administratorepost eller offentlig SSH-nøkkel. Passord, private nøkler og tokens skal ikke legges inn i skjemaet.

Forbered før du bestiller

  1. Velg et gjenkjennelig tjenestenavn for teamet ditt.
  2. Bestem om du skal bruke et eget domene eller et midlertidig vertsnavn.
  3. Forbered en offentlig SSH-nøkkel hvis tjenesten krever det.
  4. Sjekk lagringsplass og ressurser i forhold til applikasjonen du skal kjøre.

Ikke send sensitive opplysninger

Hvis du er usikker på om en opplysning er sensitiv, spør heller enn å sende den. Ikke send private nøkler, passord, tokens, databasedumper eller hele konfigurasjonsfiler i chatten eller bestillingen.

> Endre CPU, RAM, disk eller lagringstid etter bestilling

Rediger eksisterende tjeneste via detaljsiden, ikke ved å opprette en ny bestilling. Ved endring av ressurs kan pris, servicekostnad, daglig kredittforbruk, omstart og risiko for nedetid endres.
faq/change-service-resources-after-order

Endrer du en eksisterende tjeneste, eller oppretter du en ny?

Hvis tjenesten allerede kjører, gjør endringer i ressursene fra dens detaljside. En ny bestilling vil opprette en ekstra tjeneste i stedet for å redigere den eksisterende, og kan endre pris, daglig kredittforbruk og driftsatferd etter bekreftelse, betaling og aktivering av endringen.

Før du bekrefter endringen

  1. Se nåværende CPU-, RAM- og diskplass, samt sikkerhetskopiering og Offsite Archive-retensjon.
  2. Sjekk den nye prisen og det daglige kredittforbruket.
  3. Les varsler om omstart, vedlikehold eller driftsstans.
  4. Lag en sikkerhetskopi av viktige data før du gjør en risikabel endring.

Hva skjer hvis endringen ikke går som planlagt

Send tjenestens navn, tidspunkt for endringen, synlig status og eventuelle feilmeldinger. Ikke send private nøkler, passord eller tokens; offentlig kontekst og et skjermbilde med sensitive data usynlige er tilstrekkelig for feilsøking.

> Avbestilling av tjenesten og sletting av data

En aktivert tjeneste blir først suspendert. Det vises en synlig og konfigurerbar slettefrist, etterfulgt av permanent sletting i henhold til livssyklusinnstillinger.
faq/cancel-service-and-data-retention

Avbestilling fører ikke alltid til umiddelbar sletting

Når en tjeneste allerede er aktivert, blir den vanligvis suspendert først, og det vises en konfigurerbar tidsfrist før permanent sletting kan finne sted. Ubetalte bestillinger som ennå ikke er opprettet, kan ha en annen prosess.

Før du kansellerer

  1. Lag din egen eksport av data som du trenger å lagre over tid.
  2. Les dato og klokkeslett for planlagt sletting når tjenesten er suspendert.
  3. Husk at sikkerhetskopiering og Offsite Archive er separate fra automatisk sletting av tjenesten.
  4. Hvis du er usikker, kontakt support før slettingen.

Gjenoppretting etter fristen er kanskje ikke mulig

Etter utløpt synlig tidsperiode skal dataene ikke regnes som tilgjengelige. Ved spørsmål, vennligst oppgi ordrenummer og tjenestenavn, ikke databasenotater eller hemmelige påloggingsdetaljer.

> Sikkerhetskopier og forespørsler om gjenoppretting

Sikkerhetskopier brukes til operativ gjenoppretting, ikke som en erstatning for eksport; gjenoppretting kan overskrive nyere data.
faq/backups-and-restore-requests

Sikkerhetskopier er ikke et arkiv eller en eksport

Lagringstiden for sikkerhetskopier avhenger av det valgte produktet og alternativene. Sikkerhetskopier brukes til gjenoppretting etter feil, men erstatter ikke egen eksport, revisjonsarkiv eller Offsite Archive. En gjenoppretting kan overskrive nyere endringer.

Hvordan forberede en gjenopprettingsforespørsel

  1. Oppgi navnet på tjenesten og ordrenummeret.
  2. Beskriv omtrent hvilket tidspunkt du ønsker å gå tilbake til.
  3. Angi om hele tjenesten eller en bestemt del skal gjenopprettes, hvis det støttes.
  4. Legg ved tydelige feilmeldinger eller kontekst, men unngå å inkludere passord, tokens eller private nøkler.

Vurder konsekvensene før du gjenoppretter

Hvis tjenesten har mottatt nye data i mellomtiden, kan gjenopprettingen overskrive disse med en eldre versjon. Informer teamet før du bekrefter gjenopprettingen, og ta backup av det du ikke ønsker å miste.

> Hva er formålet med Offsite Archive?

Offsite Archive lagrer eksterne arkivkopier, adskilt fra vanlige sikkerhetskopier og tjenestens slettefunksjoner. Den fungerer ikke som direkte lagring for aktive applikasjoner.
faq/offsite-archive-purpose

Arkiv utenfor normal drift

Offsite Archive brukes til fjerntlagrede arkivkopier og lagring av data over lengre tid. Det er ikke en disk for applikasjoner, en erstatning for lokal eksport eller det samme som korte operasjonelle sikkerhetskopier.

Når bør du bruke den?

  1. Bruk dette for data du ønsker å lagre selv utenfor normal drift av tjenesten.
  2. Velg antall oppbevaringsdager basert på krav, forretningsmessige behov eller gjenopprettingsmål.
  3. Vær oppmerksom på at prisen øker i henhold til lagret volum og oppbevaringstid.
  4. Ved store datamengder, planlegg arkivet sammen med din egen eksportprosess.

Hvordan vurdere prisen

Grunnlaget er MB-dager: hvor mye data som lagres og hvor mange dager de beholdes. Prisen vises til kunden som EUR/GB/måned, og resultatet rundes av til hele cent.

> Velg CPU, RAM og disk for VPS

Velg størrelsen på VPS-en basert på applikasjonen, databasen, cachen, loggene og forventet vekst. OOM (ut av minne) eller bruk av swap indikerer ofte at du trenger mer RAM.
faq/vps-cpu-ram-and-disk-sizing

Start ut fra faktisk belastning, ikke magefølelse

En liten statisk nettside har andre behov enn en database, Java-applikasjon, søk eller en container for bygging. Når du planlegger, ta hensyn til minnebruk, cache, databaser, logger, opplastinger og reserver for vekst.

Tegn som indikerer at planen er for liten

  1. Øk RAM-mengden når du opplever OOM-feil (out of memory), prosesser som avsluttes eller hyppig bruk av swap-minne.
  2. Øk CPU-kraften ved langvarig høy databehandling, komprimering, bygging eller intensiv aktivitet i applikasjonskomponenter.
  3. Øk diskplassen før filsystemet, loggfilene eller databasen blir full.
  4. Etter hver endring, sjekk om applikasjonen faktisk har sluttet å støte på den opprinnelige begrensningen.

Hva bør du sende når du har spørsmål om størrelse?

Det kan være nyttig å inkludere tjenestens navn, type applikasjon, synlige feilmeldinger, omtrentlig tidspunkt for problemet og gjeldende CPU-, RAM- og diskbruk. Ikke send passord, private nøkler eller interne konfigurasjonsfiler.

> Når gir det mening med en offentlig IP-adresse for en VPS?

En dedikert offentlig IP-adresse kan være nyttig for tillatelseslister, ekstern tilgang, en stabil utgående kilde eller tjenester som er knyttet til en bestemt adresse.
faq/vps-public-ip-options

Finn ut hvilken retning kommunikasjonen går i

En offentlig IP-adresse er ikke nødvendig for alle tjenester. Den brukes ofte til å dekke behovene til eksterne partnere, leverandører eller brannmurer som krever en stabil adresse for tillatelseslister, en stabil utgående kilde eller tilgang til en bestemt port.

Spørsmål før du bestiller IP-adresse

  1. Spør partneren om tillatelseslisten gjelder innkommende, utgående eller begge retninger.
  2. Bruk DNS-navn i stedet for numeriske IP-adresser der det er mulig.
  3. Åpne kun de portene applikasjonen faktisk trenger.
  4. Send forespørselen om tillatelsesliste til support før du endrer produksjonstilgangen.

Hva du bør la være lukket

En offentlig IP-adresse betyr ikke at alle porter er åpne. Begrens tilgangen til de minimum nødvendige tjenestene, og send ikke passord, private nøkler eller interne brannmurregler som skjermbilder med sensitive verdier.

> Felles SSH-tilgang for VPS

Uten en kjøpt, dedikert IP-adresse kobler VPS-en din via et felles SSH-endepunkt med en høy port. Med en dedikert IP-adresse vil du også få direkte SSH-tilgang til denne adressen.
faq/shared-ssh-access-for-vps

Hvorfor bruker delt SSH en høy port?

Flere VPS-tjenester kan dele samme offentlige SSH-tilkobling, derfor får hver tjeneste sin egen høye port. Porten er en del av rutingen til din spesifikke tjeneste; uten den ville ikke tilkoblingen kunne leveres sikkert til riktig VPS.

Hvordan koble til, avhengig av tilgangstype

  1. Når du bruker delt SSH, kopier brukernavnet, verten og porten fra SSH-tjenesten.
  2. Bruk kommandoen ssh -p <port> <brukernavn>@<offentlig_vert>.
  3. Hvis tjenesten har en dedikert offentlig IP-adresse, kan den også ha et direkte SSH-endepunkt på denne IP-adressen eller dens DNS-navn.
  4. Bruk kun den private nøkkelen lokalt via din egen SSH-klient eller agent; kontakt support med offentlig host, port, brukernavn og synlig feilmelding.

Når du har kjøpt en offentlig IP-adresse

En offentlig IP-adresse endrer ikke den delte SSH-endepunktet; den legger til en separat måte å få tilgang på som er egnet for tillatelseslister, overvåking eller direkte tilkobling. I praksis kan du derfor se to SSH-tilganger: en delt host med høy port og en dedikert host eller IP-adresse for tjenesten med en offentlig IP-adresse.

> Kontroll før du kobler til ditt eget domene

Før du bytter domene, må du sjekke autoritativ DNS, nøyaktig vertsnavn, om det er et toppnivådomene eller en underdomene, og eventuelle konflikter med gamle oppføringer.
faq/custom-domain-readiness-checklist

Det nøyaktige vertsnavnet er viktig

Først må du finne ut om du kobler til et toppnivådomene som example.com eller en subdomene som app.example.com. Hver variant kan kreve en annen type DNS-oppføring, andre begrensninger fra DNS-leverandøren og verifisering hos registeret.

Før du endrer DNS

  1. Velg det nøyaktige toppnivådomenet eller subdomenet, for eksempel example.com eller app.example.com.
  2. Bekreft autoriteten til registrar eller navneserver og fjern konflikterende oppføringer for samme vertsnavn før du legger til den nye målrettingen.
  3. Bruk CNAME, A/AAAA, ALIAS eller ANAME kun der DNS-leverandøren din, registraren og vertstypen tillater det.
  4. Etter endringen, vent på at DNS-endringene spres og test HTTPS-tilkoblingen før du fortsetter.

Sikker tilbakestilling

Slå ikke av den gamle serveren før det nye vertsnavnet fungerer som forventet. Hvis du opplever problemer, vennligst oppgi domenet, det forventede målet og DNS-resultatene, men ikke tilgangsopplysninger til registreringsportalen.

> Typer DNS-poster for tjenester

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

Ikke bland DNS-recordtyper vilkårlig

Hver DNS-rekordtype har en annen funksjon. A- og AAAA-poster peker til IP-adresser, CNAME oppretter et alias for en underdomene, MX dirigerer e-post, TXT inneholder verifikasjoner og e-postpolicyer, og CAA begrenser sertifiseringsmyndigheter.

Når du kopierer inn oppføringer

  1. Kopier navn, type og verdi nøyaktig i henhold til instruksjonene fra tjenesten.
  2. Bruk ikke CNAME på en hostname som allerede har andre oppføringer, hvis DNS-reglene forbyr det.
  3. Plasser DKIM under leverandørens selector og DMARC vanligvis under _dmarc.
  4. Vær forsiktig når du konfigurerer CAA, da feilaktige verdier kan hindre utstedelse av sertifikater.

Når DNS ikke fungerer

Send support følgende informasjon: vertsnavn, type oppføring, forventet verdi og synlig resultat. Ikke send innloggingsinformasjon til DNS-administrasjon eller skjermbilder som inneholder API-tokens.

> DNS-propagering og TTL – ingen garanti for nøyaktig tid

TTL (Time To Live) bestemmer hvor lenge en resolver kan lagre et gammelt svar. Under overgangen kan både gamle og nye resultater eksistere parallelt.
faq/dns-propagation-and-ttl

Propagering er en cache, ikke magi

Når en autoritativ endring i DNS gjøres, kan forskjellige løsere fortsatt returnere gamle svar inntil TTL-en utløper. Derfor kan resultatet variere mellom nettverk, land eller DNS-løsere.

Ved planlagte endringer

  1. Reduser TTL-verdien før en planlagt endring, hvis DNS-leverandøren tillater det.
  2. Gjør DNS-endringen én gang og unngå gjentatte endringer mens cachen utløper.
  3. Test fra flere resolver eller nettverk når svarene er forskjellige.
  4. Noter ned tidspunktet for endringen, den gamle verdien, den nye verdien og TTL.

Hva du bør sende inn ved feilsøking

Oppgi hostname, ønsket mål, synlig gammel respons, synlig ny respons, TTL og tidspunktet for endringen. Ikke send innloggingsinformasjon til DNS-konto eller interne notater fra leverandøren.

> Planlegging av lagringsplass for Workspace Suite

Inkluder brukerfiler, delte mapper, versjoner, søppelkasse, forhåndsvisninger, synkroniseringskostnader og forventet vekst i kapasitetsberegningen.
faq/nextcloud-storage-planning

Workspace Suite bruker plass også utenfor de synlige filene

Lagringsplassen brukes av brukerfiler, delte mapper, slettede filer, versjonshistorikk, forhåndsvisninger, miniatyrbilder, synkroniseringsklienter og importer. Hvis lagringen nærmer seg grensen, kan opplasting eller synkronisering feile.

Før du bestiller kapasitet

  1. Beregn dagens brukerdata og fellesmapper.
  2. Legg til ekstra plass for slettede filer, versjonshistorikk, forhåndsvisninger og synkroniseringsaktivitet.
  3. Ta hensyn til store innlastinger, nye team og forventet vekst.
  4. Øk lagringskapasiteten før brukere opplever begrensninger.

Problemer med synkronisering?

Send informasjon om tjenestens størrelse, omtrentlig bruk, tidspunkt for problemet og synlige feilmeldinger fra kunden. Ikke send personlige filer, passord eller eksport av brukerdata med mindre support eksplisitt ber om det på en sikker måte.

> Migrering av repositories til Gitea

Planlegg migreringen av Git-repositories, inkludert LFS, submoduler, rettigheter, deploy keys, webhooks og CI/CD.
faq/gitea-repository-migration

Migrering er mer enn bare et git-klon

I tillegg til repositoryhistorikken, må du også overføre eller konfigurere på nytt eiere, team, beskyttede grener, beskyttede tagger, Git LFS, submoduler, deploy keys, webhooks og CI/CD-integrasjoner.

Kontroll før overgang

  1. Opprett repositorier, eiere, grupper og automatiseringskontoer.
  2. Sjekk Git LFS-objekter, undermoduler, beskyttede grener og tagbeskyttelser.
  3. Test kloning, push, Git LFS, undermoduler og CI-kjøringer etter overføringen.
  4. Bytt ut eller fjern gamle tokens etter at migreringen er bekreftet, uten å dele tokenverdier.

Sensitive data under migrering

Send kun navn på repositorier, type integrasjon, synlig feilmelding og informasjon om hva som fungerte før migreringen til support.

> Avsendingsdomene for Listmonk

Forbered et avsenderdomene eller et underdomene for kampanjer, inkludert From-identitet, SPF, DKIM, DMARC, returmeldinger og avmeldingsmuligheter.
faq/listmonk-sender-domain-basics

Levering starter med domenet

Listmonk fungerer best når avsenderdomenet har riktige DNS-oppføringer, en tydelig "From"-identitet, SPF, DKIM, DMARC-tilpasning, håndtering av returmeldinger og informasjon om avmelding og identitet. Publiser SPF hos e-postleverandøren, DKIM med leverandørens velger og DMARC på _dmarc. Send testmeldinger før en ekte kampanje og del ikke e-posthemmeligheter.

Før din første kampanje

  1. Velg et sendernavn eller subdomene, og angi 'Fra'-navnet.
  2. Legg til DNS-poster for verifisering, inkludert SPF, DKIM-selektor og DMARC.
  3. Test levering, returmeldinger og lenker i e-posten.
  4. Sjekk avmeldingsfunksjonen og List-Unsubscribe før du sender ut en produksjonskampanje.

E-posthemmeligheter hører ikke hjemme i en supporthenvendelse

Når du rapporterer problemer, oppgi domenet, typen registrering, den offentlig synlige DNS-verdien og feilmeldingen. Ikke send SMTP-passord, API-nøkler, private DKIM-nøkler eller eksport av mottakerlister som inneholder personopplysninger.

> Innstillinger for kjøretid for Classic Hosting

Classic Hosting kan kjøre i automatisk eller manuell modus. CPU, RAM, minne, lagringsplass, sikkerhetskopiering, arkivering utenfor nettstedet, opplastinger, cache og logger påvirker både kostnadene og stabiliteten.
faq/classic-hosting-runtime-settings

Automatisk modus er nyttig, men ikke alltid riktig

Automatisk kjøremiljø hjelper med kjente PHP-, Node.js-, Java-, Python-, .NET-, Go- og Ruby-prosjekter. Manuell modus er best når du ønsker å styre Nginx, Apache, FrankenPHP eller språkvalg mer presist. PHP-valget gjelder kun der det valgte kjøremiljøet støtter det.

Innstillinger før distribusjon

  1. Velg automatisk eller manuell kjøremodus basert på rammeverk og byggeprosess.
  2. Velg PHP 8.2, 8.3 eller 8.4 kun for støttede PHP-scenarioer.
  3. Konfigurer CPU, RAM, diskplass, backup-retensjon og Offsite Archive-retensjon basert på data og trafikk.
  4. Etter distribusjon, test opplastinger, cache, logger og synlige applikasjonsfeil.

Når applikasjonen ikke starter

Send runtime-modus, språk eller PHP-versjon, synlig feilmelding, hva som ble endret og omtrentlig tidspunkt for distribusjonen. Ikke send .env-filer, passord, tokens eller hele logger med sensitive verdier.

> Hvilken informasjon kan du trygt sende til support?

Det som er mest nyttig for oss å få er ordrenummer, tjenestenavn, domener, tidspunkter, offentlige hoster og porter, retensjon av sikkerhetskopier, retensjon av Offsite Archive, opplastinger, cache-informasjon, logger, skjermbilder og synlige feil. Unngå å sende sensitiv informasjon.
faq/support-safe-information-to-share

En god henvendelse inneholder relevant informasjon, ikke konfidensielle data.

Support kan svare raskere når de mottar ordrenummer, tjenestenavn, domene, offentlig host eller port, tidspunkt for problemet, hva som ble endret og en nøyaktig feilmelding.

Sikker innhold i meldingen

  1. Oppgi ordrenummer, tjeneste, domene, tidspunkt og trinn der problemet oppstod.
  2. For hosting: Oppgi runtime, PHP- eller språkversjon, CPU, RAM, lagringsplass, opplastinger, cache og logger uten sensitive data.
  3. Beskjær skjermbilder før du sender dem, og fjern sensitiv informasjon.
  4. Hvis du er usikker på om informasjonen hører hjemme i en sak, spør først før du sender den.

Hva du aldri bør sende

Ikke send passord, private nøkler, API-nøkler, gjenopprettingsfraser, databaseeksporter eller fullstendige logger med sensitive verdier.