Ofte stillede spørgsmål

Ofte stillede spørgsmål

Praktiske, korte guides til opsætning af tjenester, adgang og almindelige kundehåndtering.

> Hvordan fungerer Cli>_ kreditsystemet?

Én fælles forudbetalt saldo finansierer alle berettigede tjenester og bruges kun, mens de er aktive.
faq/prepaid-credit-how-it-works

Din Cli>_ konto har én fælles forudbetalt kreditsaldo. Berettigede nye kunder kan først gøre krav på Starter Credit, når de har gennemført den krævede konto- og antimisbrugsverificering. Aktive berettigede tjenester bruger saldoen over tid. Månedsestimatet anvender 31 dage, og en ny tjeneste kan kun starte, hvis saldoen dækker mindst 7 dage. En rød advarsel vises, når den estimerede driftstid falder under 7 dage; ellers vises en orange advarsel, når den falder under 14 dage.

Når saldoen er opbrugt, suspenderes tjenesten efter 7 dage, stopper med at bruge kredit, og opbevarings- og sletningsfristen på 7 dage begynder. Før den viste frist kan den genstartes med nok kredit. Opsigelse af en klargjort tjeneste suspenderer den også og starter samme frist. En afventende, ikke-klargjort tjeneste kan deaktiveres straks. Efter fristen begynder deaktivering og fjernelse af den klargjorte tjeneste. Force delete deaktiverer tjenesten straks, springer opbevaringen over og starter fjernelsen fra aktiv runtime; afslutningen følger deployment- og GitOps-behandlingen. Backups og Offsite Archive har separate opbevaringsregler.

Eksempel med OpenCode til 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR om dagen. Efter 10 hele dage er cirka 3,19 EUR brugt. Hvis startsaldoen var præcis 9,90 EUR uden andre tjenester, er cirka 6,71 EUR tilbage. Forbruget stopper efter deaktivering.

Eksemplet er kun vejledende. De aktuelle priser, som vises i Cli>_, er altid gældende.

> Sådan genererer du en offentlig SSH-nøgle via kommandolinjen

Opret en offentlig SSH-nøgle for sikker adgang til din VPS. Del kun den offentlige nøgle med Cli>_; behold den private nøgle på dit eget udstyr.
faq/generate-public-ssh-key-da

Brug kun den offentlige nøgle

SSH bruger et nøglepar. Indsæt kun den offentlige nøgle, normalt filen der ender på .pub, i serviceindstillingerne. Den private nøgle forbliver på din egen enhed.

Fremgangsmåde

  1. Åbn en terminal på din computer.
  2. Kør kommandoen: ssh-keygen -t ed25519 -C "din-email@example.com".
  3. Bekræft placeringen af filen, eller vælg en anden sti. Del aldrig din private nøgle med nogen.
  4. Vis den offentlige nøgle ved hjælp af kommandoen: cat ~/.ssh/id_ed25519.pub.
  5. Kopiér hele linjen, der starter med ssh-ed25519, og indsæt den i feltet "SSH public key" under bestilling eller serviceopsætning.
  6. Kopiér hele linjen, der starter med ssh-ed25519, og indsæt den i feltet "SSH public key".

Tjek før du indsætter

  1. Åbn PowerShell eller Windows Terminal.
  2. Kør kommandoen: ssh-keygen -t ed25519 -C "din-email@example.com".
  3. Tryk på Enter for at gemme nøglen til C:\Users\dit-brugernavn\.ssh\id_ed25519, eller angiv en brugerdefineret sti.
  4. Hvis Windows beder om en adgangskode, skal du bruge en, som du kan opbevare sikkert, eller tryk på Enter for at springe den over ved en simpel opsætning.
  5. Vis den offentlige nøgle ved hjælp af kommandoen: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopier kun hele linjen, der starter med ssh-ed25519. Kopier ikke eller upload filen med den private nøgle.
> Hvordan du opretter en SSH-nøgle grafisk i Windows

En visuel guide i Windows til at oprette et SSH-nøglesæt uden brug af kommandolinjen.
faq/create-ssh-key-windows-gui-da

Brug et Windows-værktøj, og indsæt kun den offentlige nøgle

Du kan oprette et SSH-nøglepar grafisk ved hjælp af en Windows SSH-klient som PuTTYgen. Cli>_ har kun brug for den offentlige nøgle. Gem den private nøgle på din computer, og upload den aldrig via en webformular.

Fremgangsmåde

  1. Installer PuTTY eller åbn PuTTYgen, hvis du allerede har den installeret.
  2. Vælg EdDSA/Ed25519, hvis det er tilgængeligt, ellers vælg RSA 4096.
  3. Klik på Generer og bevæg musen over det tomme område, indtil nøglen vises.
  4. Tilføj en adgangskode, hvis du ønsker ekstra lokal beskyttelse af den private nøgle.
  5. Gem den private nøgle på din computer og hold den fortrolig.
  6. Kopiér teksten med den offentlige nøgle og indsæt den i feltet til SSH-offentlig nøgle.

Del ikke følsomme data

Send aldrig .ppk-filer, private nøgler, adgangskoder eller tokens til support eller i formularer.

> Tilføj dit eget domæne

Lær hvordan du retter dit eget domæne eller underdomæne til en CLIopen-service, inden du aktiverer funktionen 'Brug din egen domæne'.
faq/tilslut-dit-eget-domaene

Hvad denne indstilling gør

Funktionen "Brug dit eget domæne" giver din service mulighed for at svare på dit eget værtsnavn, f.eks. app.example.com, i stedet for kun at bruge det genererede *.co.cliopen.cloud-værtsnavn. Dit DNS skal pege på CLIopen, før værtsnavnet sikkert kan bruges af tjenesten.

Før du starter

  1. Vælg det præcise værtsnavn, du ønsker at bruge, f.eks. app.example.com. Det er nemmest at bruge et underdomæne.
  2. Åbn DNS-administrationen hos din domæneregistrator eller DNS-udbyder.
  3. Fjern eventuelle konflikterende A-, AAAA-, CNAME-, ALIAS- eller omdirigeringsposter for det samme værtsnavn.
  4. Hold det automatisk genererede CLIopen-hostname aktivt, indtil dit brugerdefinerede hostname er verificeret og fuldt funktionelt.

Anbefalet DNS-opsætning for et underdomæne

Opret DNS-poster for det præcise værtsnavn, som du indtaster i CLIopen. For app.example.com er DNS-mærkningen app. Peg den på CLIopen ingress-adresserne, som du modtager fra CLIopen support eller i servicevejledningen. Hvis din udbyder beder om en posttype, skal du bruge en 'A'-post til IPv4 og en 'AAAA'-post til IPv6, når disse adresser er angivet.

Eksempel:

app.example.com.  A     <CLIopen IPv4-adresse>
app.example.com.  AAAA  <CLIopen IPv6-adresse, hvis den er tilgængelig>

Når CLIopen angiver et CNAME-mål

Visse tjenester kan give dig et genereret værtsnavn, f.eks. service.customer.co.cliopen.cloud. Hvis instruktionerne for din tjeneste specifikt kræver en CNAME, skal du oprette en registrering som f.eks. app.example.com CNAME service.customer.co.cliopen.cloud. Brug kun CNAME til underdomæner og ikke til apex/rod-domæner, medmindre din DNS-udbyder understøtter ALIAS eller ANAME flattening.

Brug af roddomænet

For et toplevel-domæne som example.com tillader de fleste DNS-udbydere ikke en standard CNAME-record. Brug A/AAAA-records, der peger på CLIopen ingress-adresserne, eller brug din udbyders ALIAS/ANAME-funktion, hvis CLIopen har leveret et hostname.

Delegering af hele subdomæne

Hvis du ønsker, at CLIopen skal administrere records under en underzone som apps.example.com, skal du oprette NS-records for denne underzone, der peger på de CLIopen-navneservere, du har modtaget. Ændr ikke nameserverne for hele domænet, medmindre du bevidst ønsker, at CLIopen (eller en anden DNS-tjeneste) skal administrere alle records.

Tjekliste

  1. Vent på DNS-propagering. Små ændringer er ofte synlige inden for få minutter, men nogle udbydere cache' længere.
  2. Kontroller, at værtsnavnet peger på CLIopen-målet og ikke på en tidligere udbyder.
  3. Indtast det præcise værtsnavn i feltet "Brug dit eget domæne" uden `https://` og uden sti.
  4. Efter opdateringen, test `https://app.example.com` i din browser.
  5. Behold gamle DNS-poster kun hvis de ikke er i konflikt med det nye værtsnavn.
> Sådan overføres en DNS-zone til CLIopen

Delegér et domæne til ns1.cliopen.com og ns2.cliopen.com, så CLIopen kan publicere records for hele zonen.
faq/overdrag-en-dns-zone

Hvad betyder zonetransfer her?

Når det drejer sig om kundespecifik DNS, betyder overførsel en ændring af de autoritative navneservere hos din domæneregistrator. Efter at delegationen er rettet mod CLIopen, publiceres DNS-records, der er tilføjet i CLIopen DNS, fra vores autoritative navneservere.

Før du ændrer nameservere

  1. Kopier eksisterende DNS-poster, som du stadig har brug for, f.eks. websted, e-mail, verifikationer, SPF, DKIM, DMARC og serviceposter.
  2. Tilføj zonen i CLIopen DNS. Hvis delegeringen ikke er klar endnu, gemmer CLIopen den, men aktiverer den ikke for kunderne, før valideringen er gennemført.
  3. Opret de nødvendige poster i CLIopen DNS, inden du skifter navneservere, hvis det er muligt.
  4. Vær omhyggelig med CAA-indstillingerne, da forkerte værdier kan blokere udstedelse af certifikater.

Deleger zonen

  1. Åbn domæneindstillingerne hos din registrar, f.eks. example.com.
  2. Find nameservere, DNS-delegering eller autoritative DNS-indstillinger.
  3. Udskift de eksisterende nameservere med ns1.cliopen.com og ns2.cliopen.com.
  4. Gem ændringen og vent på, at registreringen og resolverne opdateres.

Validering

Gå tilbage til CLIopen DNS og klik på 'Tjek delegation igen'. Når de offentlige NS-poster viser ns1.cliopen.com og ns2.cliopen.com, vil zonen blive sat i kø til synkronisering, og posterne bliver aktive fra CLIopen.

> Oprettelse af konto og første login

Opret én erhvervskonto, indtast faktureringsoplysninger og sørg for, at dit team har adgang via e-mail.
faq/account-registration-and-login

Brug én konto til ordrer og administration

Brug din konto som et centralt sted for ordrer, faktureringsoplysninger, tjenester, domæner og kommunikation med supporten. Det er bedst at bruge en arbejds-e-mailadresse, som dit team kan få adgang til, selv efter personaleskift.

Før din første bestilling

  1. Registrer dig med din arbejds-e-mailadresse.
  2. Bekræft e-mailen, hvis siden beder om det.
  3. Udfyld faktureringsoplysninger, før du afgiver en bestilling.
  4. Når tofaktorautentificering er tilgængelig, skal du aktivere den straks efter dit første login.

Adgang for teams

Del ikke adgangskoder med kolleger via chat eller e-mail. Hvis flere personer har brug for adgang, skal I bruge en intern password manager, eller anmode om den anbefalede teamprocedure; supporten behøver ikke din adgangskode eller login-token.

> Estimat for månedligt, årligt og faktisk dagligt forbrug

Månedlige og årlige priser bruges til sammenligning; ved forudbetalte abonnementer bestemmes prisen ud fra det faktiske daglige forbrug efter bekræftelse af ændringen.
faq/billing-periods-and-credit-burn

Estimaterne er ikke en faktureringskalender

Månedlige estimater bruger 31 dage, og årlige estimater bruger 372 dage. Det faktiske forbrug af kredit sker for forudbetalte tjenester baseret på den aktive brugstid af tjenesten og den bekræftede konfiguration.

Hvad du skal tjekke ved en prisændring

  1. Sammenlign det daglige forbrug før og efter ændringen.
  2. Forvent et højere dagligt forbrug ved mere CPU, RAM eller diskplads, eller ved valgfrie betalte funktioner.
  3. Ændringen træder først i kraft efter bekræftelse, eventuel betaling og implementering.
  4. Gem ordrebekræftelser og kreditoplysninger til regnskabsbrug.

Afklar en specifik periode

Supportteamet har brug for ordrenummer, servicenavn og datoer for at kunne hjælpe dig. Send ikke bankoplysninger, komplette kontoudtog eller skærmbilleder med uønskede personlige oplysninger.

> Ordrestatus efter betaling

En ordre kan midlertidigt vente på bekræftelse fra betalingsudbyderen. Opret kun en kopi af ordren, når den første tydeligt er annulleret eller udløbet.
faq/order-status-and-payment-confirmation

Afventende betyder ikke nødvendigvis en fejl

Efter returnering fra betalingsudbyderen kan ordren stadig vente på bekræftelse. En ny, dobbelt ordre kan unødigt komplicere parringen, indtil status er tydeligt mislykket eller udløbet.

Hvad du skal gøre efter betaling

  1. Når betalingen er gennemført, skal du vende tilbage til Cli>_.
  2. Tjek ordrestatus i din konto og eventuelle beskeder relateret til betalingen.
  3. Hvis ordren stadig afventer behandling, giv leverandøren tid til at bekræfte den.
  4. Hvis du oplever problemer, send da ordrenummeret og betalingsreferencen til support, hvis du kan se den.

Hvad du ikke skal sende

Support har ikke brug for kreditkortoplysninger, adgangskoder eller hele bankudtog. Det er nok med ordrenummer, tidspunkt for betaling, synlig status og et sløret skærmbillede, hvis der vises en fejl.

> Oplysninger, der fremskynder opsætningen af tjenesten

Forbered servicenavn, domæne, lagerplads, adgangse-mail og offentlig SSH-nøgle; hemmeligheder hører ikke til i formularer.
faq/service-setup-information-needed

Nøjagtige oplysninger sparer tid

Brug ordreformularen til offentlige eller ikke-følsomme værdier: servicenavn, domæne, DNS-plan, lagerstørrelse, CPU, RAM, admin-e-mail eller public SSH-nøgle. Adgangskoder, private nøgler og tokens skal holdes uden for formularen.

Forbered dig inden du afgiver ordren

  1. Vælg et servicenavn, som dit team kan genkende.
  2. Beslut, om du vil bruge dit eget domæne eller et midlertidigt system-hostname.
  3. Forbered en offentlig SSH-nøgle, hvis tjenesten kræver det.
  4. Tjek lagerplads og ressourcer i forhold til den applikation, du skal køre.

Send ikke fortrolige oplysninger

Hvis du er usikker på, om en oplysning er fortrolig, så spørg uden at sende den. Send ikke private nøgler, adgangskoder, tokens, databasedump eller hele konfigurationsfiler i chatten eller i ordren.

> Ændring af CPU, RAM, disk eller lagerplads efter bestilling

Rediger den eksisterende service via dens detaljer, ikke ved at oprette en ny, duplikeret ordre. Ved ændring af ressourcer kan prisen, serviceprisen, det daglige kreditforbrug, omstart og risiko for nedetid ændres.
faq/change-service-resources-after-order

Du ændrer en eksisterende tjeneste

Opret ikke en ny ordre, hvis du ønsker at ændre en igangværende tjeneste. Ændringer i ressourcer kan påvirke pris, dagligt kreditforbrug og drift, og de træder først i kraft efter bekræftelse, betaling (hvis nødvendigt) og implementering.

Før du bekræfter ændringen

  1. Se aktuelle oplysninger om CPU, RAM, diskplads, backup og Offsite Archive-opbevaring.
  2. Tjek den nye dagspris og dens indvirkning på dit kreditforbrug.
  3. Læs advarsler om genstart, vedligeholdelse eller nedetid.
  4. Lav din egen eksport af vigtige data før en risikabel ændring.

Hvis ændringen ikke sker som forventet

Send servicenavn, tidspunkt for ændringen, synlig status og fejlmeddelelse. Send ikke private nøgler, adgangskoder eller tokens; til diagnosticering er det nok med den offentlige kontekst og et maskeret skærmbillede.

> Opsigelse af service og databeholdning

Den provisionerede tjeneste pauses først, og der vises en synlig, konfigurerbar slettefrist, hvorefter den kan slettes permanent.
faq/cancel-service-and-data-retention

Opsigelse medfører ikke altid øjeblikkelig sletning

Når en tjeneste er blevet aktiveret, suspenderes den først, og der vises en konfigurerbar tidsfrist for sletning, inden den permanent fjernes. Ubetalte ordrer, der endnu ikke er blevet aktiveret, kan blive deaktiveret uden samme datalivscyklus.

Før du annullerer

  1. Opret din egen dataeksport, hvis du ønsker at gemme dataene permanent.
  2. Læs datoen og tidspunktet for den planlagte sletning, når tjenesten er suspenderet.
  3. Husk, at backup-opbevaring og Offsite Archive-opbevaring adskiller sig fra lifecycle-sletning.
  4. Kontakt support før fristen, hvis du er i tvivl.

Gendannelse efter fristen er muligvis ikke mulig.

Efter udløbet af den viste periode bør data ikke betragtes som tilgængelige. Angiv ordrenummer og tjenestens navn, når du stiller spørgsmål; undgå at dele databaseeksporter eller loginoplysninger.

> Sikkerhedskopier og anmodninger om gendannelse

Sikkerhedskopier bruges til operationel genopretning, ikke som en erstatning for eksport; gendannelse kan overskrive nyere data.
faq/backups-and-restore-requests

Backup er ikke et arkiv eller en eksport

Opbevaring af backups afhænger af det valgte produkt og de valgte muligheder. Backup hjælper med at gendanne systemet efter fejl, men erstatter ikke din egen eksport, revisionsarkiv eller Offsite Archive. En gendannelse kan overskrive nyere ændringer.

Sådan forbereder du en gendannelsesanmodning

  1. Angiv servicenavn og ordrenummer.
  2. Beskriv omtrentligt tidspunkt for den ønskede gendannelse.
  3. Skriv, om hele tjenesten eller en bestemt del skal gendannes.
  4. Vedlæg synlige fejl eller kontekst uden adgangskoder, tokens eller private nøgler.

Overvej konsekvenserne inden gendannelse

Hvis tjenesten har modtaget nye data i mellemtiden, kan gendannelsen overskrive den nyeste tilstand med en ældre version. Informer teamet og eksporter de data, du ikke ønsker at miste, før du bekræfter gendannelsen.

> Hvad er formålet med Offsite Archive?

Offsite Archive opbevarer fjerne arkivkopier, der er adskilte fra korte driftsbackup og service-livscyklus.
faq/offsite-archive-purpose

Arkiv uden for normal drift

Offsite Archive bruges til fjerne arkivkopier og længere tids datalagring. Det er ikke en live disk til applikationer, en erstatning for lokal eksport eller det samme som kortvarige operationelle backups.

Hvornår skal det aktiveres?

  1. Brug det til data, du ønsker at opbevare uden for den normale drift af tjenesten.
  2. Vælg antallet af opbevaringsdage i henhold til compliance-krav, forretningsmæssige behov eller gendannelsesmål.
  3. Hold øje med, at prisen stiger i forhold til den lagrede mængde og den tid, dataene opbevares.
  4. Planlæg arkivering sammen med din egen eksportproces, når du har store datamængder.

Hvordan man tænker om prisen

Grundlaget er MB-dage: hvor mange data der er gemt, og hvor mange dage de opbevares. Prisen vises for kunden som EUR/GB/måned, og resultatet rundes til hele cent.

> Vælg CPU, RAM og disk til din VPS

Vælg størrelsen på din VPS baseret på dine behov for applikationer, databaser, cache, logfiler og forventet vækst. OOM (ud af hukommelse) eller brug af swap indikerer, at du muligvis har brug for mere RAM.
faq/vps-cpu-ram-and-disk-sizing

Start ud fra den faktiske belastning, ikke en fornemmelse

En simpel statisk hjemmeside har andre behov end en database, en Java-applikation, søgning eller en container med builds. Når du planlægger, skal du tage højde for applikationshukommelse, cache, databaser, logfiler, uploads og plads til vækst.

Tegn på, at planen er for lille

  1. Øg RAM, når der opstår OOM-fejl (out of memory), processer afsluttes eller der sker konstant swapping.
  2. Øg CPU vedvarende høj beregningsbelastning, komprimering, builds eller travle applikationsprocesser.
  3. Øg diskplads, før filsystemet, logfilerne eller databasen fyldes op.
  4. Efter hver ændring skal du kontrollere, om applikationen rent faktisk har stoppet med at ramme den oprindelige grænse.

Hvad skal du sende, når du har spørgsmål om størrelsen?

Angiv tjenestens navn, applikationstype, synlig fejl, omtrentligt tidspunkt og aktuel CPU-, RAM- og diskbrug. Send ikke adgangskoder eller interne konfigurationsfiler.

> Hvornår giver det mening med en offentlig IP-adresse for en VPS?

En dedikeret offentlig IP-adresse kan være nyttig til tilladelseslister, indgående adgang, en stabil udgående kilde eller tjenester, der er bundet til en adresse.
faq/vps-public-ip-options

Find først trafikretningen

En offentlig IP-adresse er ikke nødvendig for alle tjenester. Den bruges ofte til at imødekomme krav fra eksterne partnere, udbydere eller firewalls vedrørende tilladelseslister, en stabil udgående kilde eller adgang til specifikke porte.

Spørgsmål før bestilling

  1. Spørg din samarbejdspartner, om de tillader inbound, outbound eller begge retninger på listen over tilladte forbindelser.
  2. Brug DNS-navne i stedet for numeriske IP-adresser, hvor det er muligt.
  3. Åbn kun de porte, som applikationen faktisk har brug for.
  4. Send anmodningen om tilladelsesliste til support, før du ændrer produktionsadgangen.

Hvad skal holdes lukket

En offentlig IP-adresse betyder ikke, at alle porte er åbne. Begræns adgangen til de absolut nødvendige tjenester, og send ikke adgangskoder, private nøgler eller interne firewall-regler som skærmbilleder med følsomme oplysninger.

> Fælles SSH-adgang til VPS

Uden en købt offentlig IP-adresse oprettes forbindelse til VPS'en via et fælles SSH-endepunkt med en høj port; med en offentlig IP-adresse er direkte SSH også tilgængeligt på denne adresse.
faq/shared-ssh-access-for-vps

Hvorfor bruger delt SSH en høj port?

Flere VPS-tjenester kan dele det samme offentlige SSH-endepunkt, derfor får hver tjeneste sin egen høje port. Porten er en del af routingprocessen til din tjeneste; uden den kan forbindelsen ikke leveres entydigt til den korrekte VPS.

Sådan opretter du forbindelse afhængigt af adgangstype

  1. Når du bruger delt SSH, skal du kopiere brugernavn, host og port fra servicevisningen.
  2. Brug kommandoen ssh -p <port> <brugernavn>@<public-host>.
  3. Hvis tjenesten har en dedikeret offentlig IP-adresse, kan den også vise et andet SSH-endepunkt direkte på denne IP-adresse eller dens DNS-navn.
  4. Brug kun den private nøgle lokalt via din SSH-klient eller agent; del kun den offentlige host, port, brugernavn og synlige fejlmeddelelser med supporten.

Når du har købt en offentlig IP-adresse

En offentlig IP-adresse erstatter ikke nødvendigvis det delte SSH-endepunkt. Den tilføjer en separat direkte forbindelse, så du kan se både en delt host med en høj port og en direkte host/IP for den samme VPS.

> Kontrol før tilslutning af dit eget domæne

Før du skifter domæne, skal du kontrollere de autoritative DNS-indstillinger, det præcise værtsnavn, recordtypen, om det er et apex- eller subdomæne, og om der er konflikter med gamle records.
faq/custom-domain-readiness-checklist

Det præcise værtsnavn er afgørende

Først skal du afklare, om du tilknytter et apex-domæne som example.com eller et subdomæne som app.example.com. Hver variant kan kræve en anden type DNS-record, andre begrænsninger fra din DNS-udbyder og kontrol hos registraren.

Før du ændrer DNS

  1. Find ud af, hvor de autoritative DNS-records redigeres for domænet.
  2. Fjern eller ret konflikterende A/AAAA-, CNAME-, ALIAS-, ANAME- eller omdirigeringsposter.
  3. Brug den recordtype, der anbefales til den pågældende tjeneste og værtsnavn.
  4. Vent på DNS-propagering, før du tester den endelige HTTPS-forbindelse.

Sikker gendannelse

Sluk ikke for den gamle hosting, før det nye værtsnavn fungerer korrekt. Hvis der opstår problemer, del domænet, det forventede mål og det synlige DNS-resultat, men ikke adgangskoder til din registrar.

> Typer af DNS-records for tjenester

A/AAAA-records peger på adresser, CNAME-records bruges til aliaser, MX-records bruges til e-mail, og TXT-records bruges til verifikationer, SPF, DKIM eller DMARC.
faq/dns-record-types-for-services

Bland ikke poster tilfældigt

A- og AAAA-poster peger på IP-adresser, CNAME opretter et alias for en underdomæne, MX styrer e-mail, TXT indeholder verifikationer og e-mailpolitikker, og CAA begrænser certifikatmyndigheder.

Når du kopierer records

  1. Kopier navn, type og værdi nøjagtigt efter instruktionerne fra tjenesten.
  2. Brug ikke CNAME på et hostname, der allerede har andre records, hvis DNS-reglerne forbyder det.
  3. Placer DKIM under udbyderens selector og DMARC typisk under _dmarc.
  4. Vær forsigtig med CAA, da en forkert værdi kan blokere udstedelsen af certifikater.

Når DNS ikke fungerer

Send hostname, record-type, forventet værdi og det offentligt synlige resultat til supporten. Send ikke loginoplysninger til DNS-administration eller skærmbilleder med API-tokens.

> DNS-propagering og TTL – ingen garanti for minutter

TTL bestemmer, hvor længe resolvere kan gemme et gammelt svar; under overgangen kan både gamle og nye resultater eksistere samtidig.
faq/dns-propagation-and-ttl

Propagation er caching, ikke magi

DNS har ikke et fast løfte om tid. Efter en ændring i den autoritative DNS kan forskellige resolver stadig vise gamle eller nye svar, indtil deres cache udløber efter TTL-værdien. Derfor kan resultatet variere mellem netværk, lande eller DNS-resolver.

Ved planlagt ændring

  1. Hvis din udbyder tillader det, skal du reducere TTL før en planlagt ændring.
  2. Foretag DNS-ændringen én gang og undgå gentagne ændringer, mens cachen udløber.
  3. Test fra flere resolver-servere, hvis resultaterne er forskellige.
  4. Notér ændringstidspunktet, den gamle værdi, den nye værdi og TTL.

Hvad skal du sende ved diagnose

Angiv hostname, forventet resultat, det synlige gamle svar, det synlige nye svar, TTL og tidspunktet for ændringen. Send ikke adgangsoplysninger til DNS-kontoen eller interne notater fra udbyderen.

> Planlægning af lagerplads til Workspace Suite

Ved beregning af den nødvendige lagerplads skal du medtage brugerfiler, delte mapper, versioner, papirkurv, thumbnails, synkroniseringsomkostninger og forventet vækst.
faq/nextcloud-storage-planning

Workspace Suite vokser også ud over de synlige filer

Lagringspladsen bruges af brugerfiler, delte mapper, slettede filer, versionshistorik, forhåndsvisninger, miniaturebilleder, synkroniseringsklienter og importer. Hvis lageret nærmer sig grænsen, kan upload eller synkronisering fejle.

Før du bestiller kapacitet

  1. Beregn den aktuelle mængde brugerdata og delte mapper.
  2. Tilføj ekstra plads til slettede filer, versionshistorik, forhåndsvisninger og synkroniseringsaktivitet.
  3. Tag højde for store importfiler, nye teams og forventet vækst.
  4. Øg lagerpladsen, før brugerne når grænsen.

Hvis du oplever problemer med synkronisering

Send service størrelse, omtrentligt forbrug, tidspunkt og synlig fejl fra klienten. Send ikke personlige filer eller eksport af brugerdata, medmindre support specifikt anmoder om det via en sikker metode.

> Migration af repositories til Gitea

Planlæg migrationen af Git-repositories sammen med LFS, submoduler, rettigheder, deploy keys, webhooks og CI/CD.
faq/gitea-repository-migration

Migration er mere end bare et git-klon

Ud over repositoryets historik skal ejere, teams, beskyttede branches, beskyttede tags, Git LFS, submoduler, deploy keys, webhooks og CI/CD-forbindelser flyttes eller genoprettes.

Kontrol før overgang

  1. Opret en liste over repositories, ejere, adgangsgrupper og automatiske konti.
  2. Kontroller Git LFS-objekter, submoduler og beskyttede branches/tags.
  3. Test kloning, push, Git LFS, submoduler og CI-kørsel efter flytningen.
  4. Roter eller annuller gamle tokens efter migrationen er bekræftet uden at dele token-værdierne.

Følsomme data under migrering

Send ikke tokens, private nøgler, den private del af deploy keys eller CI-hemmeligheder. Del kun repository-navne, integrationstype, synlige fejl og information om, hvad der fungerede før migrationen.

> Afsenderdomæne for Listmonk

Forbered et afsenderdomæne eller en underdomæne til dine kampagner. Konfigurer også From-identitet, SPF, DKIM, DMARC, bounce-håndtering og afmeldingsmuligheder.
faq/listmonk-sender-domain-basics

Levering starter med domænet

Listmonk kræver en klar afsenderidentitet og DNS-poster, som e-mailsystemerne kan verificere. SPF, DKIM og DMARC skal være korrekt konfigureret for det domæne eller subdomæne, du ønsker at sende kampagner fra.

Før din første kampagne

  1. Vælg et afsenderdomæne eller subdomæne, og angiv et 'From'-navn.
  2. Tilføj de nødvendige DNS-poster til verifikation, herunder SPF, DKIM-vælger og DMARC.
  3. Test levering, returmeddelelser (bounce) eller Return-Path og links.
  4. Tjek afmeldingsmulighederne og List-Unsubscribe, før du sender.

Mailhemmeligheder hører ikke til i supporthenvendelser

Når du diagnosticerer, del domænet, record-typen, det offentligt synlige DNS-resultat og fejlmeddelelsen. Del ikke SMTP-adgangskoder, API-tokens, private DKIM-nøgler eller modtagerlister med personlige oplysninger.

> Runtime-indstillinger for Classic Hosting

Classic Hosting kan køre i automatisk eller manuel runtime. CPU, RAM, lagerplads, backup-opbevaring, opbevaring af Offsite Archive, uploads, cache og logs påvirker både pris og stabilitet.
faq/classic-hosting-runtime-settings

Automatisk tilstand er ikke altid det rigtige valg

Auto Runtime hjælper med projekter, der kan genkendes automatisk, men manuel tilstand er bedre, når du vil vælge Nginx, Apache, FrankenPHP eller en bestemt sprogruntime. PHP-versionen bruges kun, hvor den valgte runtime understøtter det.

Indstillinger før implementering

  1. Vælg automatisk eller manuel Runtime baseret på framework og buildmetode.
  2. Vælg PHP 8.2, 8.3 eller 8.4 kun for understøttede PHP-scenarier.
  3. Konfigurer CPU, RAM, diskplads, backup-retention og Offsite Archive baseret på data og trafik.
  4. Efter implementeringen skal du teste uploads, cache, logs og synlige applikationsfejl.

Når applikationen ikke starter

Angiv runtime-tilstand, sprog eller PHP-version, synlig fejl, hvad der er blevet ændret og omtrentligt tidspunkt for implementeringen. Send ikke .env-filer, adgangskoder, tokens eller komplette logfiler med følsomme oplysninger.

> Hvilke oplysninger kan du sikkert sende til support?

Det er mest nyttigt at inkludere ordrenumre, servicenavne, domæner, tidspunkter, offentlige hosts, porte, backup-retention, Offsite Archive-retention, uploads, cache, logfiler, skærmbilleder og synlige fejl uden fortrolige oplysninger.
faq/support-safe-information-to-share

En god henvendelse indeholder relevant information, ikke fortrolige data.

Support kan reagere hurtigere, når de modtager ordrenummer, servicenavn, domæne, offentlig host eller port, tidspunkt for problemet, hvilke ændringer der er foretaget og en præcis fejlmeddelelse.

Sikkerhed i beskeden

  1. Angiv ordrenummer, service, domæne, tidspunkt og det trin, hvor problemet opstod.
  2. Ved hosting skal du angive runtime, PHP- eller sprogversion, CPU, RAM, diskplads, uploads, cache og logs uden at inkludere følsomme data.
  3. Beskær eller slør følsomme oplysninger på skærmbilleder før afsendelse.
  4. Hvis du er usikker på, om en information hører til i billetten, så spørg først uden at sende den.

Send aldrig dette

Send ikke adgangskoder, private nøgler, gendannelseskoder, API-nøgler, session cookies, databaseeksporter, hele .env-filer, fulde logfiler med følsomme oplysninger eller interne infrastrukturdetaljer.