Vanliga frågor

Vanliga frågor

Praktiska, korta guider för att konfigurera tjänster, få tillgång till dem och utföra vanliga kundåtgärder.

> Hur fungerar Cli>_ kreditsystemet?

Ett gemensamt förbetalt saldo finansierar alla berättigade tjänster och förbrukas bara medan de är aktiva.
faq/prepaid-credit-how-it-works

Ditt Cli>_ konto har ett gemensamt förbetalt kreditsaldo. Berättigade nya kunder kan göra anspråk på Starter Credit först efter att de har slutfört den obligatoriska konto- och missbruksverifieringen. Aktiva berättigade tjänster förbrukar saldot över tid. Månadsberäkningen använder 31 dagar och en ny tjänst kan bara starta om saldot räcker i minst 7 dagar. En röd varning visas när den beräknade drifttiden sjunker under 7 dagar; annars visas en orange varning när den sjunker under 14 dagar.

När saldot är slut stängs tjänsten av efter 7 dagar, slutar förbruka kredit och lagrings- och raderingsperioden på 7 dagar börjar. Före den visade tidsfristen kan den startas om med tillräcklig kredit. Uppsägning av en etablerad tjänst stänger också av den och startar samma period. En väntande, ännu inte etablerad tjänst kan inaktiveras direkt. Efter tidsfristen påbörjas inaktivering och borttagning av den etablerade tjänsten. Force delete inaktiverar tjänsten direkt, hoppar över lagringen och startar borttagningen från aktiv runtime; slutförandet följer deployment- och GitOps-behandlingen. Säkerhetskopior och Offsite Archive har separata lagringsregler.

Exempel med OpenCode för 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR per dag. Efter 10 hela dagar har cirka 3,19 EUR förbrukats. Om startsaldot var exakt 9,90 EUR och inga andra tjänster fanns återstår cirka 6,71 EUR. Förbrukningen upphör efter inaktivering.

Exemplet är endast illustrativt. De aktuella priserna som visas i Cli>_ gäller alltid.

> Hur man genererar en offentlig SSH-nyckel via kommandotolken

Skapa en offentlig SSH-nyckel för säker åtkomst till din VPS. Dela endast den offentliga nyckeln med Cli>_; behåll den privata nyckeln på din egen enhet.
faq/generate-public-ssh-key-sv

Den publika nyckeln delas, den privata nyckeln stannar hos dig

Infoga endast den publika SSH-nyckeln i beställningen eller tjänstens inställningar. Den privata nyckeln förblir på din dator och skickas inte till supporten eller anges i ett webbformulär.

Instruktioner

  1. Öppna terminalen på din dator.
  2. Kör kommandot: ssh-keygen -t ed25519 -C "din-e-post@example.com".
  3. Bekräfta var filen ska sparas eller välj en egen sökväg. Skicka aldrig din privata nyckel till någon.
  4. Visa den publika nyckeln genom att köra kommandot: cat ~/.ssh/id_ed25519.pub.
  5. Kopiera hela raden som börjar med ssh-ed25519 och klistra in den i fältet för SSH-offentlig nyckel under beställning eller servicekonfiguration.
  6. Kopiera hela raden som börjar med ssh-ed25519 och klistra in den i fältet "SSH Public Key".

Kontrollera före inklistring

  1. Öppna PowerShell eller Windows Terminal.
  2. Kör kommandot: ssh-keygen -t ed25519 -C "din-epost@example.com".
  3. Tryck på Enter för att spara nyckeln till C:\Users\ditt-användarnamn\.ssh\id_ed25519, eller ange en egen sökväg.
  4. Om Windows frågar efter ett lösenord, använd ett som du kan lagra säkert, eller tryck på Enter för att hoppa över det vid enkel installation.
  5. Visa den publika nyckeln med kommandot: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopiera endast hela raden som börjar med ssh-ed25519. Kopiera eller ladda inte upp filen med den privata nyckeln.
> Hur man skapar en SSH-nyckel grafiskt i Windows

En grafisk guide i Windows för att skapa ett SSH-nyckelpar utan att använda kommandoraden.
faq/create-ssh-key-windows-gui-sv

Använd ett Windows-verktyg och klistra in endast den publika nyckeln

Du kan skapa ett SSH-nyckelpar visuellt med en Windows-klient som PuTTYgen. Cli>_ behöver bara den publika nyckeln. Behåll den privata nyckeln på din dator och ladda aldrig upp den via ett webbformulär.

Instruktioner

  1. Installera PuTTY eller öppna PuTTYgen om den redan är installerad.
  2. Välj EdDSA/Ed25519 om det är tillgängligt, annars välj RSA 4096.
  3. Klicka på Generera och för musen över det tomma området tills nyckeln genereras.
  4. Lägg till en lösenfras om du vill ha extra lokalt skydd för den privata nyckeln.
  5. Spara den privata nyckeln på din dator och håll den konfidentiell.
  6. Kopiera texten för den publika nyckeln och klistra in den i fältet för SSH-publika nyckel.

Dela inte känslig information

Skicka aldrig .ppk-filer, privata nycklar, lösenord eller tokens till supporten eller via formulär.

> Ta med din egen domän

Lär dig hur du dirigerar din egen domän eller underdomän till en CLIopen-tjänst innan du aktiverar funktionen 'Ta med din egen domän'.
faq/anslut-din-egen-doman

Vad den här inställningen gör

Med "Använd egen domän" kan din tjänst svara på ditt eget värdnamn, t.ex. app.example.com, istället för att bara använda det genererade värdnamnet *.co.cliopen.cloud. Din DNS måste peka mot CLIopen innan värdnamnet kan användas säkert av tjänsten.

Innan du börjar

  1. Välj det exakta värdnamnet du vill använda, till exempel app.example.com. Det enklaste är att använda en subdomän.
  2. Öppna DNS-administrationen hos din domänregistrator eller din DNS-leverantör.
  3. Ta bort eventuella konflikterande A-, AAAA-, CNAME-, ALIAS- eller omdirigeringsposter för samma värdnamn.
  4. Lämna det automatiskt genererade CLIopen-värdnamnet aktivt tills ditt anpassade värdnamn har verifierats och fungerar korrekt.

Rekommenderad DNS-konfiguration för en underdomän

Skapa DNS-poster för det exakta värdnamn du anger i CLIopen. För app.example.com är DNS-etiketten app. Rikta den mot CLIopens ingressadresser som tillhandahålls av CLIopen-supporten eller i din tjänstdokumentation. Om din leverantör frågar efter en posttyp, använd en 'A'-post för IPv4 och en 'AAAA'-post för IPv6 när dessa adresser tillhandahålls.

Exempel:

app.example.com.  A     <CLIopen IPv4-adress>
app.example.com.  AAAA  <CLIopen IPv6-adress, om tillgänglig>

När CLIopen tillhandahåller ett CNAME-mål

Vissa tjänster kan ge dig ett genererat värdnamn, t.ex. service.customer.co.cliopen.cloud. Om instruktionerna för din tjänst uttryckligen kräver en CNAME, skapa en post som app.example.com CNAME service.customer.co.cliopen.cloud. Använd endast CNAME för underdomäner, inte för toppdomänen, om din DNS-leverantör inte stöder ALIAS eller ANAME flattening.

Användning av rotdomänen

För en rotdomän som example.com tillåter de flesta DNS-leverantörer inte en standard CNAME-post. Använd A/AAAA-poster som pekar mot CLIopens ingressadresser, eller använd din leverantörs ALIAS/ANAME-funktion om CLIopen har tillhandahållit ett mål-hostname.

Delegera hela underdomänen

Om du vill att CLIopen ska hantera poster under en underzon som apps.example.com, skapa NS-poster för den underzinen som pekar mot de CLIopen-namnservrar du fått. Ändra inte namnservrarna för hela domänen om du inte avsiktligt vill att CLIopen (eller en annan DNS-tjänst) ska hantera alla poster.

Kontrollista

  1. Vänta tills DNS-propageringen är klar. Små ändringar syns ofta inom några minuter, men vissa leverantörer cachar längre.
  2. Kontrollera att värdnamnet pekar mot CLIopen-målet och inte mot en tidigare leverantör.
  3. Ange det exakta domännamnet i fältet "Använd din egen domän" utan `https://` och någon sökväg.
  4. Efter uppdateringen, testa `https://app.example.com` i din webbläsare.
  5. Behåll gamla DNS-poster endast om de inte är i konflikt med det nya domännamnet.
> Hur du flyttar en DNS-zon till CLIopen

Delegera domänen till ns1.cliopen.com och ns2.cliopen.com, så att CLIopen kan publicera poster för hela zonen.
faq/delegera-en-dns-zon

Vad zonöverföring betyder här

När det gäller kundens DNS innebär överföring att du ändrar de auktoritativa namnservrarna hos din domänregistrator. Efter att delegationen pekar på CLIopen publiceras DNS-poster som läggs till i CLIopen från våra auktoritativa namnservrar.

Innan du ändrar namnservrar

  1. Kopiera befintliga DNS-poster som du fortfarande behöver, till exempel webbplats, e-post, verifieringar, SPF, DKIM, DMARC och serviceposter.
  2. Lägg till zonen i CLIopen DNS. Om delegeringen inte är redo ännu, sparar CLIopen den men aktiverar den inte för kunderna tills valideringen har godkänts.
  3. Skapa de nödvändiga posterna i CLIopen DNS innan du byter namnservrar om det är möjligt.
  4. Se till att konfigurera CAA-posten korrekt, eftersom felaktiga värden kan förhindra utfärdandet av certifikat.

Delegera zonen

  1. Öppna domäninställningarna hos din registrar, till exempel example.com.
  2. Leta efter inställningar för nameservers, DNS-delegering eller auktoritativ DNS.
  3. Ersätt de befintliga nameservrarna med ns1.cliopen.com och ns2.cliopen.com.
  4. Spara ändringen och vänta tills registreringen har spridits till servrarna.

Validering

Gå tillbaka till CLIopen DNS och klicka på Kontrollera delegationen igen. När de publika NS-posterna visar ns1.cliopen.com och ns2.cliopen.com, kommer zonen att läggas i kö för synkronisering, och posterna blir aktiva från CLIopen.

> Skapa konto och logga in

Skapa ett företagsanvändarkonto, lägg till faktureringsuppgifter och se till att ditt team har åtkomst via en e-postadress som de kan behålla.
faq/account-registration-and-login

Ett konto för både beställningar och administration

Använd kontot som en central plats för beställningar, faktureringsinformation, tjänster, domäner och kommunikation med supporten. Det är bäst att använda en arbetsmejladress som teamet kan ha tillgång till även efter personalförändringar.

Innan din första beställning

  1. Registrera dig med din arbetsmejl.
  2. Bekräfta e-postmeddelandet om sidan ber om det.
  3. Fyll i faktureringsuppgifter innan du gör en betald beställning.
  4. Aktivera tvåfaktorsautentisering så snart den är tillgänglig.

Åtkomst för team

Dela inte lösenord med kollegor via chatt eller e-post. Om flera personer behöver åtkomst, använd en intern lösenordshanterare eller följ rekommenderade rutiner för team; supporten behöver inte ditt lösenord eller inloggningsuppgifter.

> Uppskattad månadskostnad, årlig kostnad och faktisk daglig användning

Månads- och årskostnader används för jämförelse; vid förbetalda tjänster debiteras krediten per aktiv dag efter bekräftelse av beställning eller ändring.
faq/billing-periods-and-credit-burn

Uppskattningarna är inte en faktureringskalender

Använd månadsuppskattningen som en jämförelse för 31 dagar och årsestimatet som en jämförelse för 372 dagar. Den faktiska användningen av krediten för prenumerationstjänster sker baserat på den aktiva tjänstetiden och den bekräftade konfigurationen.

Vad du bör kontrollera vid en prisändring

  1. Jämför den dagliga användningen före och efter ändringen.
  2. Om du väljer mer CPU, RAM eller diskutrymme, räkna med en högre daglig förbrukning.
  3. Ändringen träder i kraft först när den har bekräftats, eventuellt betalts och tillämpats.
  4. För redovisningsändamål, spara orderbekräftelser och historik över krediten.

Utred en specifik tidsperiod

Supporten behöver ordernummer, tjänstnamn och datum för att kunna kontrollera din användning. Skicka inte bankuppgifter, kompletta kontoutdrag eller skärmdumpar med oönskade personuppgifter.

> Beställningsstatus efter betalning

Beställningen kan behöva vänta på bekräftelse från betaltjänsten innan den behandlas; skapa inte en dubblett förrän den första beställningen tydligt har avbrutits eller gått ut.
faq/order-status-and-payment-confirmation

"Pending" betyder inte automatiskt ett fel

Efter att du återvänt från betalningssidan kan beställningen fortfarande vänta på en bekräftelse från betalningsleverantören. En dubbelbeställning kan försvåra matchningen om den första beställningen senare bekräftas.

Vad du ska göra efter betalningen

  1. Efter att betalningen är slutförd, återgå till Cli>_.
  2. Kontrollera orderstatusen i ditt konto och eventuella meddelanden relaterade till betalningen.
  3. Om beställningen fortfarande väntar, ge leverantören tid att bekräfta.
  4. Om du har problem, kontakta supporten med ordernumret och referens för betalningen, om du ser den.

Vad du inte ska skicka

Support behöver inte kortuppgifter, lösenord eller hela bankbekräftelser. Det räcker med ordernummer, tidpunkt för betalningen, synlig status och en maskerad skärmdump om ett felmeddelande visas.

> Information som snabbar på konfigurationen av din tjänst

Förbered tjänstens namn, domän, lagringsutrymme, e-postadress för åtkomst och en offentlig SSH-nyckel; hemliga uppgifter ska inte anges i formulär.
faq/service-setup-information-needed

Exakta värden sparar tid

Använd beställningsformulären för publika eller icke-hemliga värden: tjänstens namn, domän, DNS-plan, lagringsstorlek, CPU, RAM, administratörsmejl eller offentlig SSH-nyckel. Lösenord, privata nycklar och tokens ska inte anges i formulären.

Förbered innan du slutför din beställning

  1. Välj ett tydligt namn för din tjänst som ditt team känner igen.
  2. Bestäm om du vill använda en egen domän eller ett tillfälligt system-hostname.
  3. Förbered en offentlig SSH-nyckel om tjänsten kräver det.
  4. Kontrollera lagringsutrymme och resurser baserat på applikationen du ska köra.

Skicka inte konfidentiell information

Om du är osäker på om en uppgift är konfidentiell, fråga hellre utan att skicka den. Skicka inte privata nycklar, lösenord, tokens, databasdumpar eller hela konfigurationsfiler till chatten eller i beställningen.

> Ändra CPU, RAM, disk eller lagringsutrymme efter beställning

Redigera den befintliga tjänsten via dess detaljsida, inte genom att skapa en ny dubblettbeställning. Vid ändring av resurser kan priset, servicekostnaden, daglig kreditförbrukning, omstart och risken för driftstopp påverkas.
faq/change-service-resources-after-order

Ändra en befintlig tjänst, skapa inte en ny

Om tjänsten redan är aktiv, gör ändringar i resursanvändningen från dess detaljsida. En ny beställning skapar en helt ny tjänst istället för att uppdatera den befintliga och kan påverka priset, den dagliga kreditförbrukningen samt tjänstens funktion efter bekräftelse, betalning och tillämpning av ändringen.

Innan du bekräftar ändringen

  1. Se aktuell information om CPU, RAM, disk, säkerhetskopiering och Offsite Archive-retention.
  2. Kontrollera det nya dagspriset och hur det påverkar din kredit.
  3. Läs eventuella meddelanden om omstart, underhåll eller driftstopp.
  4. Gör en egen export av viktig data innan du gör riskabla ändringar.

Vad händer om förändringen inte sker som förväntat

Skicka tjänstens namn, tidpunkt för ändringen, synlig status och eventuella felmeddelanden. Skicka inte privata nycklar, lösenord eller tokens; för felsökning räcker det med offentlig kontext och en maskerad skärmdump.

> Avbryt service och datalagring

Den aktiverade tjänsten pausas först. En synlig och konfigurerbar period visas innan data permanent raderas.
faq/cancel-service-and-data-retention

Att avsluta är inte alltid omedelbar borttagning

När en tjänst har aktiverats, pausas den först och det visas en konfigurerbar tidsperiod innan den tas bort permanent. Under denna period kan du återställa eller exportera data. Väntande beställningar som ännu inte är aktiverade och saknar aktiv data kan ha ett annat beteende, och den permanenta raderingen sker först efter att livscykeln har löpt ut.

Innan du raderar, kontrollera

  1. Skapa din egen dataexport för information som du behöver spara under lång tid.
  2. Läs datum och tid för planerad radering när tjänsten är pausad.
  3. Förväxla inte säkerhetskopior och Offsite Archive med lifecycle-radering.
  4. Om du är osäker, kontakta supporten innan borttagningsdatumet.

Återställning kanske inte är möjlig efter tidsgränsen

Efter att den synliga tidsfristen har löpt ut ska data inte betraktas som tillgänglig. Ange ordernummer och tjänstens namn när du kontaktar oss, men inkludera inga databasutdrag eller inloggningsuppgifter.

> Säkerhetskopieringar och återställningsförfrågningar

Säkerhetskopior används för driftåterställning, inte som en ersättning för export; återställning kan skriva över nyare data.
faq/backups-and-restore-requests

Säkerhetskopiering är inte ett arkiv eller en export

Lagringstiden för säkerhetskopior beror på den valda produkten och inställningarna. Säkerhetskopior hjälper till vid driftstörningar, men ersätter inte egen export eller Offsite Archive. Återställning kan skriva över nyare ändringar.

Hur du förbereder en återställningsbegäran

  1. Ange tjänstens namn och ordernummer.
  2. Beskriv ungefär vilken tidpunkt du vill återgå till.
  3. Skriv om hela tjänsten eller en specifik del ska återskapas, om det stöds.
  4. Bifoga ett tydligt felmeddelande eller sammanhang utan lösenord, tokens eller privata nycklar.

Tänk på effekterna innan du återställer

Om tjänsten har tagit emot nya data under tiden kan återställningen ersätta dem med ett äldre tillstånd. Informera teamet och exportera den information du inte vill förlora innan du bekräftar återställningen.

> Vad är syftet med Offsite Archive?

Offsite Archive lagrar fjärrarkiverade kopior separat från korta driftskopier och tjänstens livscykel.
faq/offsite-archive-purpose

Arkivering utanför normal drift

Offsite Archive används för fjärrarkiverade kopior och långtidslagring av data. Det är inte en aktiv disk för applikationer, ett alternativ till lokal export eller samma sak som korta operativa säkerhetskopieringar.

När ska man aktivera det?

  1. Använd detta för data som du vill behålla även utanför tjänstens normala drift.
  2. Välj antalet dagar för lagring baserat på efterlevnadskrav, affärsbehov eller återställningsmål.
  3. Håll koll på att priset ökar beroende på den lagrade datamängden och lagringstiden.
  4. Planera arkivet tillsammans med din egen exportprocess när du hanterar stora datamängder.

Hur man tänker kring priset

Grunden är MB-dagar: hur mycket data som lagras och hur många dagar den behålls. Priset visas för kunden som EUR/GB/månad, och resultatet avrundas till hela cent.

> Välj CPU, RAM och disk för din VPS

Välj storlek på din VPS baserat på applikationen, databasen, cachen, loggarna och den förväntade tillväxten. Om du upplever OOM (minnesfel) eller swapning indikerar det att du kan behöva mer RAM.
faq/vps-cpu-ram-and-disk-sizing

Börja med den faktiska belastningen, inte bara en känsla

En liten statisk webbplats har andra behov än en databas, Java-applikation, sökning eller container med byggen. När du planerar, tänk på applikationsminne, cache, databas, loggar, uppladdningar och utrymme för tillväxt.

Tecken på att planen är för liten

  1. Öka RAM-minnet om du får felmeddelanden om OOM (out of memory), processer som avslutas eller konstant användning av swap-utrymme.
  2. Öka CPU:n vid långvarig hög processoranvändning, komprimering, byggprocesser eller när applikationsprocesserna är hårt belastade.
  3. Öka diskutrymmet innan filsystemet, loggarna eller databasen blir fulla.
  4. Efter varje ändring, kontrollera om applikationen verkligen slutat att nå den ursprungliga gränsen.

Vad ska jag skicka in när jag har en fråga om storlek?

Det hjälper att inkludera tjänstens namn, applikationstyp, synligt felmeddelande, ungefärlig tid för problemet och aktuell CPU-, RAM- och diskutrymme. Skicka inte lösenord, privata nycklar eller interna konfigurationsfiler.

> När är det meningsfullt med en publik IP-adress för en VPS?

En dedikerad publik IP-adress kan vara användbar för att skapa allowlistor, möjliggöra inkommande åtkomst, ge en stabil utgående källa eller för tjänster som är kopplade till en specifik adress.
faq/vps-public-ip-options

Ta reda på trafikens riktning

En publik IP-adress är inte alltid nödvändig för varje tjänst. Den används ofta för att uppfylla krav från externa partners, leverantörer eller brandväggar gällande tillåtelser (allowlist), en stabil utgående källa eller åtkomst till en specifik port.

Frågor innan du beställer en IP-adress

  1. Fråga din partner om de tillåter inkommande, utgående eller båda typer av anslutningar i sin allowlista.
  2. Använd DNS-namn istället för numeriska IP-adresser där det är möjligt.
  3. Öppna endast de portar som applikationen faktiskt behöver.
  4. Skicka din begäran om tillåtna adresser till supporten innan du ändrar produktionsåtkomsten.

Vad du bör hålla stängt

En publik IP-adress innebär inte att alla portar är öppna. Begränsa åtkomsten till de absolut nödvändiga tjänsterna och skicka inte lösenord, privata nycklar eller interna brandväggsregler som skärmdumpar med hemlig information.

> Delad SSH-åtkomst för VPS

Utan en köpt publik IP-adress ansluter VPS:en via en delad SSH-slutpunkt med en hög port. Med en publik IP-adress finns det även möjlighet till direkt SSH-anslutning på den adressen.
faq/shared-ssh-access-for-vps

Varför används en hög port för delad SSH-åtkomst?

Flera VPS-tjänster kan dela samma publika SSH-anslutning, därför får varje tjänst sin egen höga port. Porten är en del av routningen till din tjänst; utan den kan anslutningen inte levereras korrekt till rätt VPS.

Hur du ansluter beroende på åtkomsttyp

  1. När du använder delad SSH, kopiera användarnamn, publika värd och port exakt som de visas i tjänsten.
  2. Anslut med ssh -p <port> <användarnamn>@<publik-värd> från din lokala terminal.
  3. Om tjänsten har en dedikerad publik IP-adress kan den också visa en andra SSH-anslutning direkt på IP-adressen eller dess DNS-namn.
  4. Använd den privata nyckeln endast lokalt via din SSH-klient eller agent; till supporten ska du endast lämna information om den publika servern, porten, användarnamnet och eventuella synliga fel.

När du har köpt till en publik IP-adress

En publik IP-adress ersätter inte nödvändigtvis en delad SSH-anslutning. Den lägger till ett separat sätt att ansluta som är lämpligt för vitlistor, övervakning eller direkt anslutning. I praktiken kan du alltså se två typer av SSH-anslutningar: en delad server med en hög port och en direkt server eller IP-adress för en tjänst med en publik IP-adress.

> Kontrollera innan du ansluter din egen domän

Innan du byter domän, kontrollera den auktoritativa DNS-servern, det exakta värdnamnet, typen av post (t.ex. A eller CNAME), om det är en toppdomän eller en subdomän, och eventuella konflikter med gamla poster.
faq/custom-domain-readiness-checklist

Det exakta värdnamnet avgör valet

Först måste du klargöra om du kopplar en toppdomän som example.com eller en subdomän som app.example.com. Varje variant kan kräva en annan typ av DNS-post, andra begränsningar från din DNS-leverantör och verifiering hos registratorn.

Innan du ändrar DNS

  1. Kontrollera var de auktoritativa DNS-posterna redigeras för domänen.
  2. Ta bort eller ändra konflikterande A/AAAA-, CNAME-, ALIAS-, ANAME- eller omdirigeringsposter.
  3. Använd den typ av post som rekommenderas för den specifika tjänsten och värdnamnet.
  4. Vänta tills DNS-propageringen är klar innan du testar den slutgiltiga HTTPS-inställningen.

Säker återställning

Stäng inte av den gamla servern förrän det nya domännamnet svarar korrekt. Om du stöter på problem, ange domänen, det förväntade målet och det synliga DNS-resultatet, men dela inte inloggningsuppgifter till din registrar.

> Olika typer av DNS-poster för tjänster

A/AAAA-poster pekar till adresser, CNAME används för alias, MX för e-post och TXT för verifieringar, SPF, DKIM eller DMARC.
faq/dns-record-types-for-services

Blanda inte DNS-poster godtyckligt

Varje typ av DNS-post har en annan funktion. A- och AAAA-poster pekar på IP-adresser, CNAME skapar ett alias för en subdomän, MX dirigerar e-post, TXT innehåller verifieringar och e-postpolicyer, och CAA begränsar certifikatutfärdare.

När du kopierar poster

  1. Kopiera namnet, typen och värdet exakt enligt instruktionerna från tjänsten.
  2. Använd inte CNAME för en domännamn som redan har andra poster om DNS-reglerna förbjuder det.
  3. Placera DKIM under leverantörens selector och DMARC vanligtvis under _dmarc.
  4. Var försiktig när du konfigurerar CAA, eftersom felaktiga värden kan hindra utfärdandet av certifikat.

När DNS inte fungerar

Skicka hostname, typ av post, förväntat värde och det synliga resultatet till supporten. Skicka inte inloggningsuppgifter till DNS-administration eller skärmdumpar med API-nycklar.

> DNS-propagering och TTL – inga löften om exakt tid

TTL (Time To Live) bestämmer hur länge en resolver får behålla ett gammalt svar. Under övergången kan både gamla och nya resultat finnas samtidigt.
faq/dns-propagation-and-ttl

Propagation är en fråga om cachning, inte magi

När det gäller DNS finns det inget fast löfte om hur snabbt ändringar sprids. Efter att en auktoritativ DNS-ändring har gjorts kan olika resolver fortfarande returnera gamla och nya svar tills deras cache upphör att gälla enligt TTL. Därför kan resultatet variera mellan nätverk, länder eller DNS-resolver.

Vid planerad ändring

  1. Om din DNS-leverantör tillåter det, sänk TTL innan den planerade ändringen.
  2. Gör DNS-ändringen en gång och undvik upprepade ändringar tills cacheminnet har tömts.
  3. Testa från flera resolverar om resultaten skiljer sig.
  4. Anteckna tidpunkten för ändringen, det gamla värdet, det nya värdet och TTL.

Vad du kan skicka vid felsökning

Ange hostname, önskat mål, synligt gammalt svar, synligt nytt svar, TTL och tidpunkt för förändringen. Skicka inte inloggningsuppgifter till DNS-kontot eller interna anteckningar från leverantören.

> Planering av lagringsutrymme för Workspace Suite

Vid beräkning av lagringskapacitet, inkludera användarfiler, delade mappar, versioner, papperskorg, förhandsvisningar, synkroniseringsöverhead och teamets tillväxt.
faq/nextcloud-storage-planning

Workspace Suite växer även bortom de filer du ser

Lagringsutrymmet används av användarfiler, delade mappar, raderade filer, versionshistorik, förhandsvisningar, miniatyrbilder, synkroniseringsklienter och importer. Om lagringen närmar sig gränsen kan uppladdningar eller synkroniseringar sluta fungera.

Innan du beställer kapacitet

  1. Beräkna aktuell användardata och delade mappar.
  2. Lägg till extra utrymme för raderade filer, versionshistorik, förhandsvisningar och synkroniseringsaktivitet.
  3. Ta hänsyn till stora importåtgärder, nya team och förväntad tillväxt.
  4. Öka lagringen innan användarna når gränsen.

Problem med synkroniseringen

Skicka tjänstens storlek, ungefärlig användning, tidpunkt och synliga felmeddelanden från klienten. Skicka inte personliga filer, lösenord eller exporter av användardata om supporten inte uttryckligen begär dem på ett säkert sätt.

> Migrering av repositories till Gitea

Planera migreringen av Git-repositories i samband med LFS, submoduler, rättigheter, deploy-nycklar, webhooks och CI/CD.
faq/gitea-repository-migration

Migrering är mer än bara en git-klon

Utöver historiken måste ägare, team, skyddade branchar, skyddade taggar, Git LFS, submoduler, deploy keys, webhooks och CI/CD-anslutningar flyttas eller återskapas.

Kontroll före driftsättning

  1. Hantera repositories, ägare, åtkomstgrupper och automationskonton.
  2. Verifiera Git LFS-objekt, submoduler och skyddade brancher/taggar.
  3. Efter migreringen, testa kloning, pushning, Git LFS, submoduler och CI-körningar.
  4. Ogiltigförklara eller byt ut gamla tokens efter att migreringen har bekräftats, utan att dela tokenvärdena.

Känslig information vid migrering

Skicka inte tokens, privata nycklar, den privata delen av deploy-nycklar eller CI-hemligheter. Ange istället repositorynamn, integrationstyp, synliga felmeddelanden och information om vad som fungerade innan migreringen.

> Avsändardomän för Listmonk

Förbered sender domain eller subdomän, From-identitet, SPF, DKIM, DMARC, bounce och unsubscribe.
faq/listmonk-sender-domain-basics

Leveransen börjar vid domänen

Listmonk behöver en tydlig avsändaridentitet och DNS-poster som e-postsystem kan verifiera. SPF, DKIM och DMARC måste vara korrekt konfigurerade för den domän eller subdomän du vill skicka kampanjer från.

Före första kampanjen

  1. Välj sender domain eller subdomän och From-namn.
  2. Lägg till verifieringsrecords, SPF, DKIM selector och DMARC.
  3. Testa leverans, bounce eller Return-Path och länkar.
  4. Kontrollera unsubscribe och List-Unsubscribe före utskick.

Mailhemligheter stannar hos dig

Vid diagnos delas domän, record-typ, publikt DNS-resultat och feltext. Skicka inte SMTP-lösenord, API token, private DKIM key eller mottagarlistor med persondata.

> Körningsinställningar för Classic Hosting

Classic Hosting kan köras i automatiskt eller manuellt läge. CPU, RAM, minne, lagring, säkerhetskopiering, Offsite Archive-lagring, uppladdningar, cache och loggar påverkar både priset och stabiliteten.
faq/classic-hosting-runtime-settings

Automatisk konfiguration är inte alltid rätt val

Auto Runtime hjälper till med igenkända projekt, men manuell konfiguration är lämplig när du vill välja Nginx, Apache, FrankenPHP eller en specifik språkruntime. PHP-väljaren ska endast användas där den valda runtime stöder det.

Inställningar före driftsättning

  1. Välj automatisk eller manuell runtime beroende på ramverk och byggmetod.
  2. Välj PHP 8.2, 8.3 eller 8.4 endast för de PHP-scenarier som stöds.
  3. Konfigurera CPU, RAM, diskutrymme, backup-retention och Offsite Archive baserat på data och trafik.
  4. Efter distribution, testa uppladdningar, cacheminne, loggar och synliga applikationsfel.

När applikationen inte startar

Skicka runtime-läge, språk eller PHP-version, synliga felmeddelanden, information om vilka ändringar som gjorts och ungefärlig installationstid. Skicka inte .env-filer, lösenord, tokens eller kompletta loggar som innehåller känslig information.

> Vilken information kan du säkert skicka till support?

Det är mest användbart att inkludera ordernummer, tjänstenamn, domäner, tider, publika servrar, portar, backup-retention, Offsite Archive-retention, uppladdningar, cache, loggar, skärmdumpar och synliga fel – utan att avslöja känslig information.
faq/support-safe-information-to-share

En bra förfrågan innehåller relevant information, inte konfidentiell data.

Supporten kan svara snabbare om du inkluderar ordernummer, tjänstens namn, domän, publik server eller port, tidpunkt för problemet, vad som ändrades och ett tydligt felmeddelande.

Säkerhetsåtgärder för meddelanden

  1. Ange ordernummer, tjänst, domän, tidpunkt och det steg där problemet uppstod.
  2. Vid problem med hosting, inkludera runtime-läge, språk eller PHP-version, CPU, RAM, lagring, säkerhetskopieringens ålder, Offsite Archive-ålder, uppladdningar, cache och loggar, samt vad som har ändrats nyligen.
  3. Klipp ut känslig information från skärmbilder innan du laddar upp dem.
  4. Om du är osäker på om informationen hör till ärendet, fråga först utan att skicka den.

Vad du aldrig ska skicka

Skicka inte lösenord, privata nycklar, återställningsfraser, API-nycklar, sessionskakor, databasutdrag, hela .env-filer, fullständiga loggar med känslig information eller interna infrastrukturdetaljer.