0 - en to nb-NO translation catalogue (560 entries)

en: Network Services: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN
nb-NO: Nettverkstjenester: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

en: Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in <xref linkend="sect.x509-cert" />.
nb-NO: Nettverkstjenester er de programmene brukerne samhandler med direkte i sitt daglige arbeid. De er toppen av informasjonssystemets isfjell, og dette kapittelet fokuserer på dem — de skjulte delene de er avhengige av er den infrastrukturen vi allerede har beskrevet. De krever vanligvis krypteringsteknologien beskrevet i <xref linkend="sect.x509-cert" />.

en: Mail Server
nb-NO: E-posttjener

en: The Falcot Corp administrators selected Postfix for the electronic mail server, due to its reliability and its ease of configuration. Indeed, its design enforces that each task is implemented in a process with the minimum set of required permissions, which is a great mitigation measure against security problems.
nb-NO: Administratorene i Falcot Corp har valgt Postfix som elektronisk posttjener, fordi den er pålitelig og har et enkelt oppsett. Den har en utforming som sikrer at hver oppgave utføres i en prosess som kun har et minimalt sett nødvendige tillatelser. Dette er et godt forebyggende tiltak mot sikkerhetsproblemer.

en: <primary>email</primary><secondary>server</secondary>
nb-NO: <primary>e-post</primary><secondary>tjener</secondary>

en: <primary>email</primary><secondary>Postfix</secondary>
nb-NO: <primary>e-post</primary><secondary>Postfix</secondary>

en: <primary>server</primary><secondary>email</secondary>
nb-NO: <primary>tjener</primary><secondary>e-post</secondary>

en: <primary>server</primary><secondary>SMTP</secondary>
nb-NO: <primary>tjener</primary><secondary>SMTP</secondary>

en: <primary>mail server</primary>
nb-NO: <primary>e-posttjener</primary>

en: <emphasis>ALTERNATIVE</emphasis> The Exim4 server
nb-NO: <emphasis>ALTERNATIV</emphasis> Exim4-tjeneren

en: <primary>email</primary><secondary>Exim</secondary>
nb-NO: <primary>e-post</primary><secondary>Exim</secondary>

en: Debian uses Exim4 as the default email server (which is why the initial installation includes Exim4). The configuration is provided by a separate package, <emphasis role="pkg">exim4-config</emphasis>, and automatically customized based on the answers to a set of Debconf questions very similar to the questions asked by the <emphasis role="pkg">postfix</emphasis> package.
nb-NO: Debian bruker Exim4 som forvalgt e-posttjener (det vil si at den første installasjonen inkluderer Exim4). Oppsettet bestemmes av en egen pakke, <emphasis role="pkg">exim4-config</emphasis>, og tilpasses automatisk på grunnlag av svar på et sett Debconf-spørsmål . Spørsmålene som stilles når <emphasis role="pkg">postfix</emphasis>-pakken installeres, fungerer på tilsvarende måte.

en: The configuration can be either in one single file (<filename>/etc/exim4/exim4.conf.template</filename>) or split across a number of configuration snippets stored under <filename>/etc/exim4/conf.d/</filename>. In both cases, the files are used by <command>update-exim4.conf</command> as templates to generate <filename>/var/lib/exim4/config.autogenerated</filename>. The latter is the file used by Exim4. Thanks to this mechanism, values obtained through Exim's debconf configuration — which are stored in <filename>/etc/exim4/update-exim4.conf.conf</filename> — can be injected in Exim's configuration file, even when the administrator or another package has altered the default Exim configuration.
nb-NO: Oppsettet kan enten være i én fil (<filename>/etc/exim4/exim4.conf.template</filename>), eller delt opp i en rekke oppsettssnutter som lagres under <filename>/etc/exim4/conf.d/</filename>. I begge tilfeller bruker <command>update-exim4.conf</command> filene som maler for å lage <filename>/var/lib/exim4/config.autogenerated</filename>. Det er denne sistnevnte filen som brukes av Exim4. Takket være denne mekanismen kan verdier hentet fra Exims debconf-oppsett — som er lagret i <filename>/etc/exim4/update-exim4.conf.conf</filename> — kan legges inn i Exims oppsettsfil, selv når administratoren eller en annen pakke har endret Exims forvalgte oppsett.

en: The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation. <ulink type="block" url="https://www.exim.org/docs.html" />
nb-NO: Syntaksen til Exim4s oppsettsfil har en viss læringskurve og sine særegenheter, men når en så har forstått disse er Exim4 en svært komplett og kraftig e-posttjener, noe som gjenspeiles av de titalls sidene med dokumentasjon. <ulink type="block" url="https://www.exim.org/docs.html" />

en: Installing Postfix
nb-NO: Installasjon av Postfix

en: <primary>Postfix</primary><secondary>installation</secondary>
nb-NO: <primary>Postfix</primary><secondary>installasjon</secondary>

en: <primary>daemon</primary><secondary>SMTP</secondary>
nb-NO: <primary>bakgrunnsprosess</primary><secondary>SMTP</secondary>

en: The <emphasis role="pkg">postfix</emphasis> package includes the main <acronym>SMTP</acronym> daemon. Other packages (such as <emphasis role="pkg">postfix-ldap</emphasis> and <emphasis role="pkg">postfix-pgsql</emphasis>) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.
nb-NO: Pakken <emphasis role="pkg">postfix</emphasis> omfatter den viktigste <acronym>SMTP</acronym>-bakgrunnsprosessen. Andre pakker (slik som <emphasis role="pkg">postfix-ldap</emphasis> og <emphasis role="pkg">postfix-pgsql</emphasis>) legger til ekstra funksjonalitet i Postfix, medregnet tilgang til koblingsdatabaser. Du bør kun installere dem hvis du vet at du trenger dem.

en: <emphasis>BACK TO BASICS</emphasis> SMTP
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> SMTP

en: <acronym>SMTP</acronym> (<emphasis>Simple Mail Transfer Protocol</emphasis>, RFC 5321) is the protocol used by mail servers to exchange and route emails.
nb-NO: <acronym>SMTP</acronym> (<emphasis>Simple Mail Transfer Protocol</emphasis>), RFC 5321) er protokollen som brukes av e-posttjenere til utveksling og ruting av e-poster.

en: Several Debconf questions are asked during the installation of the package. The answers allow generating a first version of the <filename>/etc/postfix/main.cf</filename> configuration file.
nb-NO: Flere Debconf-spørsmål stilles under installasjonen av pakken. Svarene gjør det mulig å generere en første versjon av oppsettsfilen <filename>/etc/postfix/main.cf</filename>.

en: The first question deals with the type of setup. Only two of the proposed answers are relevant in case of an Internet-connected server, “Internet site” and “Internet with smarthost”. The former is appropriate for a server that receives incoming email and sends outgoing email directly to its recipients, and is therefore well-adapted to the Falcot Corp case. The latter is appropriate for a server receiving incoming email normally, but that sends outgoing email through an intermediate SMTP server — the “smarthost” — rather than directly to the recipient's server. This is mostly useful for individuals with a dynamic IP address, since many email servers reject messages coming straight from such an IP address. In this case, the smarthost will usually be the ISP's SMTP server, which is always configured to accept email coming from the ISP's customers and forward it appropriately. This setup (with a smarthost) is also relevant for servers that are not permanently connected to the internet, since it avoids having to manage a queue of undeliverable messages that need to be retried later.
nb-NO: Det første spørsmålet håndterer oppsettstypen. Bare to av de foreslåtte svarene passer for en tjenermaskin tilkoblet Internett, «Internet site» (Internett-nettsted) og «Internet with smarthost» (Internett med smartvert). Førstnevnte passer for en tjener som mottar innkommende e-post, og sender utgående e-post direkte til sine mottakere. Et oppsett av denne typen passer derfor godt i Falcot Corps tilfelle. Sistnevnte passer for en tjener som mottar innkommende e-post som normalt, men som sender utgående e-post via en mellomliggende SMTP-tjener - en «smartvert» - i stedet for direkte til mottakerens tjener. Dette er mest nyttig for personer med en dynamisk IP-adresse, siden mange e-posttjenere avviser meldinger som kommer rett fra en slik IP-adresse. I dette tilfellet vil en smartvert vanligvis være ISP-ens SMTP-tjener, som alltid er satt opp til å godta e-post som kommer fra ISP-ens (Internett-leverandørens) brukere, og videresende den på riktig måte. Dette oppsettet (med smartvert) passer også for tjenermaskiner som ikke er permanent tilkoblet Internett, fordi det ikke er nødvendig å håndtere en kø med meldinger som ikke kan leveres, for så å prøve å sende dem på nytt senere.

en: <emphasis>VOCABULARY</emphasis> ISP
nb-NO: <emphasis>ORDFORRÅD</emphasis> ISP

en: <primary>ISP, Internet Service Provider</primary><see>ISP</see>
nb-NO: <primary>ISP, Internet Service Provider (Internett-leverandør)</primary><see>ISP</see>

en: <acronym>ISP</acronym> is the acronym for “Internet Service Provider”. It covers an entity, often a commercial company, that provides Internet connections and the associated basic services (email, news and so on).
nb-NO: <acronym>ISP</acronym> er en forkortelse for «Internet Service Provider» (Internett-tjenestetilbyder. Den dekker en aktør, ofte et kommersielt selskap, som leverer Internett-tilkoblinger og tilhørende basistjenester (e-post, nyheter, osv.).

en: The second question deals with the full name of the machine, used to generate email addresses from a local user name; the full name of the machine ends up as the part after the at-sign (“@”). In the case of Falcot, the answer should be <literal>mail.falcot.com</literal>. This is the only question asked by default, but the configuration it leads to is not complete enough for the needs of Falcot, which is why the administrators run <command>dpkg-reconfigure postfix</command> so as to be able to customize more parameters.
nb-NO: Det andre spørsmålet omhandler maskinen fulle navn, som brukes til å generere e-postadresser fra et lokalt brukernavn. Maskinens fulle navn blir den delen som kommer etter at-tegnet/krøllalfa («@»). For Falcots del bør svaret være <literal>mail.falcot.com</literal>. Dette er det eneste spørsmålet ved oppstart, men det gir et oppsett som ikke dekker behovene til Falcot. Derfor bruker administratorene <command>dpkg-reconfigure postfix</command>, slik at de kan tilpasse flere parametre.

en: One of the extra questions asks for all the domain names related to this machine. The default list includes its full name as well as a few synonyms for <literal>localhost</literal>, but the main <literal>falcot.com</literal> domain needs to be added by hand. More generally, this question should usually be answered with all the domain names for which this machine should serve as an MX server; in other words, all the domain names for which the DNS says that this machine will accept email. This information ends up in the <literal>mydestination</literal> variable of the main Postfix configuration file — <filename>/etc/postfix/main.cf</filename>.
nb-NO: Ett av de ekstra spørsmålene gjelder å innhente alle domenenavnene som er tilknyttet denne maskinen. Forvalgslisten inneholder maskinens fulle navn og noen få synonymer for <literal>localhost</literal>, men hoveddomenet <literal>falcot.com</literal> må legges inn for hånd. Som regel bør dette spørsmålet besvares med alle domenenavnene denne maskinen skal tjene som MX-tjener for; med andre ord, alle domenenavnene DNS sier at denne maskinen vil ta imot e-post for. Denne informasjonen ender opp i <literal>mydestination</literal>-variabelen i Postfixs hovedoppsettsfil - <filename>/etc/postfix/main.cf</filename>.

en: <primary>server</primary><secondary>MX</secondary>
nb-NO: <primary>tjener</primary><secondary>MX</secondary>

en: <primary>MX</primary><secondary>server</secondary>
nb-NO: <primary>MX</primary><secondary>tjener</secondary>

en: <primary>DNS</primary><secondary>resource record</secondary><tertiary>MX</tertiary>
nb-NO: <primary>DNS</primary><secondary>ressurs-oppføring</secondary><tertiary>MX</tertiary>

en: Role of the DNS <emphasis>MX</emphasis> record while sending a mail
nb-NO: Rollen til DNS <emphasis>MX</emphasis>-oppføringer ved sending av e-post

en: <emphasis>EXTRA</emphasis> Querying the MX records
nb-NO: <emphasis>EKSTRA</emphasis> Spørring mot MX-oppføringene

en: <primary>DNS</primary><secondary>resource record</secondary><tertiary>A</tertiary>
nb-NO: <primary>DNS</primary><secondary>ressurs-oppføring</secondary><tertiary>A</tertiary>

en: When the DNS does not have an MX record for a domain, the email server will try sending the messages to the host itself, by using the matching A record (or AAAA in IPv6).
nb-NO: Når DNS ikke har en MX-oppføring for et domene, vil e-posttjeneren prøve å sende meldingene til verten selv ved hjelp av den tilsvarende A-oppføringen (eller AAAA i IPv6).

en: In some cases, the installation can also ask what networks should be allowed to send email via the machine. In its default configuration, Postfix only accepts emails coming from the machine itself; the local network will usually be added. The Falcot Corp administrators added <literal>192.168.0.0/16</literal> to the default answer. If the question is not asked, the relevant variable in the configuration file is <literal>mynetworks</literal>, as seen in the example below.
nb-NO: I noen tilfeller kan installasjonen også spørre hvilke nettverk som skal få lov til å sende e-post via maskinen. I forvalgsoppsettet aksepterer Postfix kun e-postmeldinger som har sitt opphav fra maskinen selv; det lokale nettverket vil vanligvis bli lagt til. Falcot Corp-administratorene la til <literal>192.168.0.0/16</literal> til det forvalgte svaret. Hvis dette spørsmålet ikke stilles, er den relevante variabelen i oppsettsfilen <literal>mynetworks</literal>, slik som i eksemplet nedenfor.

en: Local email can also be delivered through <command>procmail</command>. This tool allows users to sort their incoming email according to rules stored in their <filename>~/.procmailrc</filename> file. Both Postfix and Exim4 suggest <emphasis role="pkg">procmail</emphasis> by default, but there are alternatives like <emphasis role="pkg">maildrop</emphasis> or Sieve filters.
nb-NO: Lokal e-post kan også leveres via <command>procmail</command>. Med dette verktøyet kan brukere sortere sin innkommende e-post etter regler som hver enkelt bruker kan lagre i sin <filename>~/.procmailrc</filename>-fil. Både Postfix og Exim4 foreslår <emphasis role="pkg">procmail</emphasis> som forvalg, men det finnes alternativer som <emphasis role="pkg">maildrop</emphasis>, eller Sieve-filtre.

en: <primary>email</primary><secondary>filtering</secondary>
nb-NO: <primary>e-post</primary><secondary>filtrering</secondary>

en: <primary>filtering email</primary>
nb-NO: <primary>filtrering av e-post</primary>

en: After this first step, the administrators got the following configuration file; it will be used as a starting point for adding some extra functionality in the next sections.
nb-NO: Etter dette første trinnet, fikk administratorene følgende oppsettsfil; den vil bli brukt som utgangspunkt for å legge inn ekstra funksjonalitet i de neste delene.

en: Initial <filename>/etc/postfix/main.cf</filename> file
nb-NO: Innledende <filename>/etc/postfix/main.cf</filename>-fil

en: <emphasis>SECURITY</emphasis> <emphasis>Snake oil</emphasis> SSL certificates
nb-NO: <emphasis>SIKKERHET</emphasis> «<emphasis>Slangeolje</emphasis>»-SSL-sertifikater

en: The <emphasis>snake oil</emphasis> certificates, like the <emphasis>snake oil</emphasis> “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.
nb-NO: «<emphasis>Slangeolje</emphasis>»-sertifikatene har fått sitt navn fra <emphasis>slangeolje</emphasis>, som ble solgt som «medisin» av skruppelløse kvakksalvere i gamle dager, og de har absolutt ingen verdi. Du kan ikke stole på dem når de går god for tjeneren, siden de genereres automatisk med selvsignerte sertifikater. De kan likevel være nyttige for å gjøre utvekslingene mer private.

en: In general they should only be used for testing purposes, and normal service must use real certificates. The <link linkend="sidebar.letsencrypt">Let's encrypt</link> initiative offers free and trusted SSL/TLS certificates, which can be generated using the <emphasis role="pkg">certbot</emphasis> package as described in <xref linkend="sect.apache-ssl" /> and then used in <command>postfix</command> like this:
nb-NO: Generelt bør de kun brukes i testøyemed, der normal tjenestedrift krever ekte sertifikater. <link linkend="sidebar.letsencrypt">Let's Encrypt</link>-initiativet tilbyr gratis og pålitelige SSL/TLS-sertifikater, som kan genereres ved hjelp av <emphasis role="pkg">certbot</emphasis>-pakken som beskrevet i <xref linkend="sect.apache-ssl" />. Deretter kan de brukes i <command>postfix</command> på denne måten:

en: <primary>Postfix</primary><secondary>trusted certificates</secondary>
nb-NO: <primary>Postfix</primary><secondary>tiltrodde sertifikater</secondary>

en: <primary>certificate</primary><secondary>trusted certificate</secondary>
nb-NO: <primary>sertifikat</primary><secondary>tiltrodd sertifikat</secondary>

en: 
    smtpd_tls_cert_file = /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/fullchain.pem
    smtpd_tls_key_file = /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/privkey.pem
    smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
    smtpd_tls_CApath = /etc/ssl/certs
    smtp_tls_CApath = /etc/ssl/certs
nb-NO: 
    smtpd_tls_cert_file = /etc/letsencrypt/live/<replaceable>DOMENE</replaceable>/fullchain.pem
    smtpd_tls_key_file = /etc/letsencrypt/live/<replaceable>DOMENE</replaceable>/privkey.pem
    smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
    smtpd_tls_CApath = /etc/ssl/certs
    smtp_tls_CApath = /etc/ssl/certs

en: Configuring Virtual Domains
nb-NO: Oppsett av virtuelle domener

en: <primary>Postfix</primary><secondary>virtual domain</secondary>
nb-NO: <primary>Postfix</primary><secondary>virtuelt domene</secondary>

en: <primary>domain</primary><secondary>virtual</secondary>
nb-NO: <primary>domene</primary><secondary>virtuelt</secondary>

en: <emphasis>CAUTION</emphasis> Virtual domains and canonical domains
nb-NO: <emphasis>VÆR VARSOM</emphasis> Virtuelle domener og «kanoniske» domener

en: None of the virtual domains must be referenced in the <literal>mydestination</literal> variable; this variable only contains the names of the “canonical” domains directly associated to the machine and its local users.
nb-NO: Det må ikke vises til noen av de virtuelle domenene i <literal>mydestination</literal>-variabelen. Denne variabelen inneholder kun navnene på «kanoniske» (autoriserte) domenene som direkte knyttet til maskinen og dens lokale brukere.

en: Virtual Alias Domains
nb-NO: Virtuelle alias-domener

en: <primary>alias</primary><secondary>virtual alias domain</secondary>
nb-NO: <primary>alias</primary><secondary>virtuelt alias-domene</secondary>

en: A virtual alias domain only contains aliases, i.e. addresses that only forward emails to other addresses.
nb-NO: Et virtuelt alias-domene inneholder kun aliaser, dvs. adresser som kun videresender e-post til andre adresser.

en: Such a domain is enabled by adding its name to the <literal>virtual_alias_domains</literal> variable, and referencing an address mapping file in the <literal>virtual_alias_maps</literal> variable.
nb-NO: Et slikt domene aktiveres ved å legge til domenets navn i <literal>virtual_alias_domains</literal>-variabelen, og viser til en fil med adressetilordninger i <literal>virtual_alias_maps</literal>-variabelen.

en: The <filename>/etc/postfix/virtual</filename> file describes a mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special <literal>@domain.com</literal> syntax covers all remaining aliases in a domain.
nb-NO: Filen <filename>/etc/postfix/virtual</filename> beskriver en tilordning med en ganske grei syntaks: Hver linje inneholder to felter adskilt med mellomrom: Det første feltet er alias-navnet, det andre feltet en liste over e-postadresser det videresendes til. Den spesielle <literal>@domain.com</literal>-syntaksen dekker alle de andre aliasene innenfor et domene.

en: 
    webmaster@falcotsbrand.com  jean@falcot.com
    contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
    # The alias below is generic and covers all addresses within
    # the falcotsbrand.com domain not otherwise covered by this file.
    # These addresses forward email to the same user name in the
    # falcot.com domain.
    @falcotsbrand.com           @falcot.com
nb-NO: 
    webmaster@falcotsbrand.com  jean@falcot.com
    contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
    # Aliaset nedenfor er generisk og dekker alle adresser i domenet
    # falcotsbrand.com som ikke finnes andre steder i denne filen.
    # Disse adressene videresender e-post til brukeren med samme 
    # navn i domenet falcot.com.
    @falcotsbrand.com           @falcot.com

en: After changing <filename>/etc/postfix/virtual</filename> the postfix table <filename>/etc/postfix/virtual.db</filename> needs to be updated using <command>sudo postmap /etc/postfix/virtual</command>.
nb-NO: Når det er gjort endringer i <filename>/etc/postfix/virtual</filename>, må Postfix-tabellen i <filename>/etc/postfix/virtual.db</filename> oppdateres ved hjelp av <command>sudo postmap /etc/postfix/virtual</command>.

en: Virtual Mailbox Domains
nb-NO: Virtuelle postboks-domener

en: <primary>mailbox, virtual domain</primary>
nb-NO: <primary>postboks, virtuelt domene</primary>

en: <emphasis>CAUTION</emphasis> Combined virtual domain?
nb-NO: <emphasis>VÆR VARSOM</emphasis> Kombinert virtuelt domene?

en: Postfix does not allow using the same domain in both <literal>virtual_alias_domains</literal> and <literal>virtual_mailbox_domains</literal>. However, every domain of <literal>virtual_mailbox_domains</literal> is implicitly included in <literal>virtual_alias_domains</literal>, which makes it possible to mix aliases and mailboxes within a virtual domain.
nb-NO: Postfix tillater ikke bruk av det samme domenet i både <literal>virtual_alias_domains</literal>, og <literal>virtual_mailbox_domains</literal>. Imidlertid er alle domener i <literal>virtual_mailbox_domains</literal> implisitt inkludert i <literal>virtual_alias_domains</literal>. Dette gjør det mulig å blande flere alias og postbokser innenfor et virtuelt domene.

en: Messages addressed to a virtual mailbox domain are stored in mailboxes not assigned to a local system user.
nb-NO: Meldinger som adresseres til et virtuelt postboks-domene, lagres i postbokser som ikke er tilknyttet en lokal systembruker.

en: Enabling a virtual mailbox domain requires naming this domain in the <literal>virtual_mailbox_domains</literal> variable, and referencing a mailbox mapping file in <literal>virtual_mailbox_maps</literal>. The <literal>virtual_mailbox_base</literal> parameter contains the directory under which the mailboxes will be stored.
nb-NO: Når du skal aktivere et virtuelt postboks-domene, må du navngi dette domenet i <literal>virtual_mailbox_domains</literal>-variabelen, og vise til en fil med postbokstilordninger i <literal>virtual_mailbox_maps</literal>. Parameteret <literal>virtual_mailbox_base</literal> inneholder katalogen der postboksene vil bli lagret.

en: The <literal>virtual_uid_maps</literal> parameter (respectively <literal>virtual_gid_maps</literal>) references the file containing the mapping between the email address and the system user (respectively group) that “owns” the corresponding mailbox. To get all mailboxes owned by the same owner/group, the <literal>static:5000</literal> syntax assigns a fixed UID/GID (of value 5000 here).
nb-NO: Parameteret <literal>virtual_uid_maps</literal> (og det lignende parameteret <literal>virtual_gid_maps</literal>) viser til filen som inneholder tilordningen mellom e-postadressen og systembrukeren (henholdsvis gruppen) som «eier» den tilsvarende postboksen. Syntaksen <literal>static:5000</literal> gir en fast UID/GID (med verdien 5000) for å sørge for at alle postbokser eies av samme eier/gruppe.

en: Again, the syntax of the <filename>/etc/postfix/vmailbox</filename> file is quite straightforward: two fields separated with whitespace. The first field is an email address within one of the virtual domains, and the second field is the location of the associated mailbox (relative to the directory specified in <emphasis>virtual_mailbox_base</emphasis>). If the mailbox name ends with a slash (<literal>/</literal>), the emails will be stored in the <emphasis>maildir</emphasis> format; otherwise, the traditional <emphasis>mbox</emphasis> format will be used. The <emphasis>maildir</emphasis> format uses a whole directory to store a mailbox, each individual message being stored in a separate file. In the <emphasis>mbox</emphasis> format, on the other hand, the whole mailbox is stored in one file, and each line starting with “<literal>From </literal>” (<literal>From</literal> followed by a space) signals the start of a new message.
nb-NO: Også her er syntaksen til <filename>/etc/postfix/vmailbox</filename>-filen ganske enkel: To felt adskilt med mellomrom. Det første feltet er en e-postadresse i ett av de virtuelle domenene, og det andre feltet plasseringen av den tilhørende postboksen (i forhold til katalogen spesifisert i <emphasis>virtual_mailbox_base</emphasis>). Hvis postboksen ender med en skråstrek (<literal>/</literal>), blir e-postene lagret i <emphasis>maildir</emphasis>-formatet; ellers blir det tradisjonelle <emphasis>mbox</emphasis>-formatet brukt. Formatet <emphasis>maildir</emphasis> bruker en hel katalog for å lagre en postboks, det vil si at hver enkelt melding blir lagret i én fil. I <emphasis>mbox</emphasis>-formatet, derimot, lagres hele postboksen i én fil, og hver linje som starter med «<literal>From </literal>» (altså <literal>From</literal> fulgt av et mellomrom), signaliserer starten på en ny e-post.

en: 
    # Jean's email is stored as maildir, with
    # one file per email in a dedicated directory
    jean@falcot.org falcot.org/jean/
    # Sophie's email is stored in a traditional "mbox" file,
    # with all mails concatenated into one single file
    sophie@falcot.org falcot.org/sophie
nb-NO: 
    # E-posten til Jean lagres i maildir-formatet, med
    # en fil per e-post i en egen katalog
    jean@falcot.org falcot.org/jean/
    # E-posten til Sophie lagres i en tradisjonell mbox-fil,
    # der alle e-postene legges etter hverandre i en enkelt fil
    sophie@falcot.org falcot.org/sophie

en: Restrictions for Receiving and Sending
nb-NO: Restriksjoner for mottak og forsendelse

en: The growing number of unsolicited bulk emails (<emphasis>spam</emphasis>) requires being increasingly strict when deciding which emails a server should accept. This section presents some of the strategies included in Postfix.
nb-NO: Det økende antallet uønskede e-poster (<emphasis>spam</emphasis>) krever økt nøkternhet når man bestemmer hvilke e-postmeldinger en tjener skal akseptere. Denne delen presenterer noen av de strategiene som inngår i Postfix.

en: If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the <literal>soft_bounce = yes</literal> directive. By prepending a reject-type directive with <literal>warn_if_reject</literal> only a log message will be recorded instead of rejecting the request.
nb-NO: Hvis avvisningsreglene er for strenge, kan det hende at selv legitim e-posttrafikk blir utelåst. Det er derfor en god vane å teste restriksjoner og forhindre permanent avvisning av forespørsler i den tiden <literal>soft_bounce = ja</literal> direktivet er i bruk. Ved å forutse et avvisningsdirektiv med <literal>warn_if_reject</literal> registreres bare en loggmelding i stedet for å avvise forespørselen.

en: <emphasis>CULTURE</emphasis> The spam problem
nb-NO: <emphasis>KULTUR</emphasis> Søppelpost/spam-problemet

en: <primary>spam</primary>
nb-NO: <primary>søppelpost/spam</primary>

en: <primary>unsolicited commercial email</primary><see>spam</see>
nb-NO: <primary>uønsket e-postreklame</primary><see>søppelpost/spam</see>

en: “Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.
nb-NO: «Søppelpost» og «spam» er generelle begrep som brukes for å betegne all uønsket kommersiell e-post (også kjent som UCE-er) som oversvømmer våre elektroniske postkasser. De skruppelløse individer som sender dem, er kjent som spammere. De bryr seg lite om ubehaget de forårsaker, siden det å sende en e-post koster svært lite, og bare en svært liten andel av mottakerne trenger å dras mot tilbudene for at søppelepostoperasjonen tjener mer penger enn det koster. Prosessen er for det meste automatisert, og en offentliggjort e-postadresse (for eksempel på et nettforum, registrert på en adresseliste, eller på en blogg, og så videre) vil sannsynligvis bli oppdaget av spammernes robotkravlere, og utsatt for en endeløs strøm av uønskede meldinger. I tillegg vil hver kontakt funnet på et kompromittert system bli et mål.

en: All system administrators try to face this nuisance with spam filters, but of course spammers keep adjusting to try to work around these filters. Some even rent networks of machines compromised by a worm from various crime syndicates. Recent statistics estimate that up to 95% of all emails circulating on the Internet are spam!
nb-NO: Alle systemadministratorer prøver å møte dette ubehaget med spamfiltre, men selvfølgelig vil spammere holde seg oppdatert for å prøve å omgå disse filterne. Noen leier til og med nettverk av maskiner kompromittert med en orm fra ulike kriminelle organisasjoner. Nyere statistikk anslår at opptil 95 prosent av all e-post som sirkulerer på Internett er spam!

en: IP-Based Access Restrictions
nb-NO: IP-baserte adgangsrestriksjoner

en: <primary>email</primary><secondary>filtering on the client host</secondary>
nb-NO: <primary>e-post</primary><secondary>filtrering på klientverten</secondary>

en: The <literal>smtpd_client_restrictions</literal> directive controls which machines are allowed to communicate with the email server.
nb-NO: Direktivet <literal>smtpd_client_restrictions</literal> styrer hvilke maskiner som får lov til å kommunisere med e-posttjeneren.

en: When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior.
nb-NO: Når en variabel inneholder en regelliste, som i eksempelet nedenfor, blir disse vurdert i rekkefølge fra første til siste regel. Hver av dem kan akseptere meldingen, avvise den, eller overlate avgjørelsen til en påfølgende regel. Som konsekvens betyr rekkefølgen de er opplistet i noe, og å ganske enkelt å bytte om på to regler kan føre til helt forskjellig resultat.

en: Restrictions Based on Client Address
nb-NO: Restriksjoner basert på klientadresse

en: The <literal>permit_mynetworks</literal> directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the <literal>mynetworks</literal> configuration variable).
nb-NO: Direktivet <literal>permit_mynetworks</literal>, brukt som første regel, godtar alle e-poster som kommer fra en maskin i det lokale nettverket (som definert av oppsettsvariabelen <literal>mynetworks</literal>).

en: The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the <literal>warn_if_reject</literal> modifier to the <literal>reject_unknown_client</literal> directive: this modifier <link linkend="postfix-safety-net">turns the rejection into a simple warning recorded in the logs</link>. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.
nb-NO: Det andre direktivet vil normalt avvise e-post fra maskiner uten et helt gyldig DNS-oppsett. Et slikt gyldig oppsett betyr at IP-adressen kan tilknyttes et navn, og at dette navnet i sin tur utledes til IP-adressen. Denne begrensningen er ofte altfor streng, siden mange e-posttjenere ikke har en omvendt DNS for deres IP-adresse. Dette forklarer hvorfor Falcot-administratorene la til <literal>warn_if_reject</literal>-modifikatoren til som forvalg for <literal>reject_unknown_client</literal>-direktivet: Denne modifikatoren <link linkend="postfix-safety-net">gjør avslaget til en enkel advarsel registrert i loggen</link>. Administratorene kan deretter holde et øye med antall meldinger som ville blitt avvist hvis regelen faktisk ble håndhevet, og ta en avgjørelse senere hvis de ønsker å muliggjøre slik håndheving.

en: <emphasis>TIP</emphasis> <emphasis>access</emphasis> tables
nb-NO: <emphasis>TIPS</emphasis> <emphasis>access</emphasis>-tabeller

en: The <filename>/etc/postfix/access_clientip</filename> table lists IP addresses and networks; <filename>/etc/postfix/access_helo</filename> lists domain names; <filename>/etc/postfix/access_sender</filename> contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the <command>sudo postmap /etc/postfix/<replaceable>file</replaceable></command> command.
nb-NO: Tabellen <filename>/etc/postfix/access_clientip</filename> viser IP-adresser og nettverk; <filename>/etc/postfix/access_helo</filename> lister domenenavn; <filename>/etc/postfix/access_sender</filename> inneholder e-postadresser tilhørende avsendere. Alle disse filene må omgjøres til nøkkeltabeller (et format optimalisert for rask tilgang) etter hver endring med <command>sudo postmap /etc/postfix/<replaceable>fil</replaceable></command>-kommandoen.

en: The last four rules reject any message coming from a server listed in one of the indicated blacklists. <acronym>RBL</acronym> is an acronym for <emphasis>Remote Black List</emphasis>, and <acronym>RHSBL</acronym> stands for <emphasis>Right-Hand Side Black List</emphasis>. The difference is that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.
nb-NO: De siste fire reglene avviser alle meldinger som kommer fra en tjener oppført i en av de indikerte svartelistene. <acronym> RBL</acronym> er et akronym for <emphasis>Remote Black List</emphasis>, og <acronym>RHSBL</acronym> står for <emphasis>Right-Hand Side Black List</emphasis>. Forskjellen er at førstnevnte lister IP-adresser, mens sistnevnte viser domenenavn. Det er flere slike tjenester. De viser domener og IP-adresser med dårlig omdømme, dårlig oppsatte tjenere som spammere bruker til å videresende e-postene sine, samt uventede e-postreléer som maskiner infisert med ormer eller virus.

en: <emphasis>TIP</emphasis> White list and RBLs
nb-NO: <emphasis>TIPS</emphasis> Hvitelister og RBL-er

en: Blacklists sometimes include a legitimate server that has been suffering an incident. In these situations, all emails coming from one of these servers would be rejected unless the server is listed in a whitelist defined by <filename>/etc/postfix/access_clientip</filename>.
nb-NO: Svartelister omfatter noen ganger en legitim tjener som har vært offer for en lei hendelse. I slike situasjoner vil alle e-poster som kommer fra en av disse tjenerne bli avvist med mindre tjeneren er oppført i en hviteliste definert av <filename>/etc/postfix/access_clientip</filename>.

en: Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received.
nb-NO: Av forsiktighetshensyn anbefales det derfor å inkludere alle tiltrodde tjenere, som mange e-poster vanligvis kommer fra, i hvitelisten(e) .

en: Checking the Validity of the <literal>EHLO</literal> or <literal>HELO</literal> Commands
nb-NO: Sjekking av gyldigheten til <literal>EHLO</literal> eller <literal>HELO</literal>-kommandoer

en: <primary>email</primary><secondary>filtering on the mail host</secondary>
nb-NO: <primary>e-post</primary><secondary>filtering på e-postvertsmaskinen</secondary>

en: Each SMTP exchange starts with a <literal>HELO</literal> (or <literal>EHLO</literal>) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in <literal>smtpd_helo_restrictions</literal> the <literal>smtpd_helo_required</literal> option needs to be enabled. Otherwise clients could skip the restrictions by not sending any <literal>HELO</literal>/<literal>EHLO</literal> command.
nb-NO: Hver SMTP-utveksling starter med en <literal>HELO</literal> (eller <literal>EHLO</literal>)-kommando, etterfulgt av navnet på e-posttjeneren som utfører forsendelsen. Det kan være interessant å sjekke gyldigheten for dette navnet. For å fullt ut håndheve restriksjonene oppført i <literal>smtpd_helo_restrictions</literal> må alternativet <literal>smtpd_helo_required</literal> aktiveres. Ellers kan klienter hoppe over restriksjonene ved å ikke sende <literal>HELO</literal>/<literal>EHLO</literal>-kommandoen.

en: Restrictions on the name announced in <literal>EHLO</literal>
nb-NO: Restriksjoner på navnet som er meldt i <literal>EHLO</literal>

en: 
    smtpd_helo_required = yes
    smtpd_helo_restrictions =
        permit_mynetworks,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        warn_if_reject reject_unknown_helo_hostname,
        check_helo_access hash:/etc/postfix/access_helo,
        reject_rhsbl_helo multi.surbl.org
nb-NO: 
    smtpd_helo_required = ja
    smtpd_helo_restrictions =
        permit_mynetworks,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        warn_if_reject reject_unknown_helo_hostname,
        check_helo_access hash:/etc/postfix/access_helo,
        reject_rhsbl_helo multi.surbl.org

en: The first <literal>permit_mynetworks</literal> directive allows all machines on the local network to introduce themselves freely. This is important, because some email programs do not respect this part of the SMTP protocol adequately enough, and they can introduce themselves with nonsensical names.
nb-NO: Det første <literal>permit_mynetworks</literal>-direktivet tillater alle maskiner på det lokale nettverket å fritt legge seg til. Dette er viktig, fordi noen e-postprogrammer ikke respekterer denne delen av SMTP-protokollen godt nok, og kan legge seg til med meningsløse navn.

en: The <literal>reject_rhsbl_helo</literal> allows to specify a black list to check the hostname against an RHSBL.
nb-NO: <literal>reject_rhsbl_helo</literal> gjør det mulig å angi en svarteliste for å kontrollere vertsnavnet mot en RHSBL.

en: Using <literal>permit_mynetworks</literal> as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the <literal>falcot.com</literal> network, for instance by adding a <literal>falcot.com REJECT You are not in our network!</literal> line to the <filename>/etc/postfix/access_helo</filename> file.
nb-NO: Å bruke <literal>permit_mynetworks</literal> som første regel har en interessant bieffekt: De påfølgende reglene gjelder kun verter utenfor det lokale nettverket. Dette tillater svartelisting av alle verter som varsler seg selv som en del av <literal>falcot.com</literal>-nettverket, for eksempel for å legge til en <literal>falcot.com REJECT You are not in our network!</literal>-linje til <filename>/etc/postfix/access_helo</filename>-filen.

en: <primary>email</primary><secondary>filtering on the sender</secondary>
nb-NO: <primary>e-post</primary><secondary>filtrering etter avsender</secondary>

en: Every message has a sender, announced by the <literal>MAIL FROM</literal> command of the SMTP protocol; again, this information can be validated in several different ways.
nb-NO: Hver melding har en avsender, annonsert av <literal>MAIL FROM</literal>-kommandoen fra SMTP-protokollen; igjen, denne informasjonen kan bli validert på flere forskjellige måter.

en: Sender checks
nb-NO: Sjekking av sender

en: The <filename>/etc/postfix/access_sender</filename> table maps some special treatment to some senders. This usually means listing some senders into a white list or a black list.
nb-NO: Tabellen <filename>/etc/postfix/access_sender</filename> gir en noe spesiell behandling for noen avsendere. Dette betyr vanligvis å liste noen av avsenderne i en hviteliste eller en svarteliste.

en: Finally, the <literal>reject_non_fqdn_sender</literal> rule rejects emails purporting to come from addresses without a fully-qualified domain name. In practice, this means rejecting emails coming from <literal>user@machine</literal>: the address must be announced as either <literal>user@machine.example.com</literal> or <literal>user@example.com</literal>.
nb-NO: Til slutt, <literal>reject_non_fqdn_sender</literal>-regelen avviser e-post som angivelig kommer fra adresser uten fullt kvalifisert domenenavn. I praksis betyr dette å avvise e-postmeldinger som kommer fra <literal>user@machine</literal>: Adressen må annonseres enten som <literal>user@machine.example.com</literal>, eller <literal>user@example.com</literal>.

en: The <literal>reject_rhsbl_sender</literal> rule reject senders based on a (domain-based) RHSBL service.
nb-NO: <literal>reject_rhsbl_sender</literal>-regelen avviser avsendere basert på en (domenebasert) RHSBL-tjeneste.

en: <primary>email</primary><secondary>filtering on the recipient</secondary>
nb-NO: <primary>e-post</primary><secondary>filtrering basert på mottaker</secondary>

en: Each email has at least one recipient, announced with the <literal>RCPT TO</literal> command in the SMTP protocol. These addresses also warrant validation, even if that may be less relevant than the checks made on the sender address.
nb-NO: Hver e-post har minst én mottager, kunngjort med <literal>RCPT TO</literal>-kommandoen i SMTP-protokollen. Disse adressene garanterer også validering, selv om det kan være mindre relevant enn kontrollene av avsenderadressen.

en: Recipient checks
nb-NO: Sjekk av mottager

en: <literal>reject_unauth_destination</literal> is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to send unsolicited emails; this rule is therefore mandatory, and it will be best included near the beginning of the list, so that no other rules may authorize the message before its destination has been checked.
nb-NO: Regelen <literal>reject_unauth_destination</literal> er den grunnleggende regelen som krever at meldinger utenfra adresseres til oss; meldinger sendt til en adresse ikke betjent med denne tjeneren blir avvist. Uten denne regelen, blir tjeneren et åpent relé som tillater spammere å sende uønsket e-post. Denne regelen er derfor obligatorisk, og tas best inn nær begynnelsen av listen, slik at ingen andre regler kan autorisere meldingen før destinasjonen er kontrollert.

en: The <literal>reject_unlisted_recipient</literal> rule rejects messages sent to non-existing local users, which makes sense. Finally, the <literal>reject_non_fqdn_recipient</literal> rule rejects non-fully-qualified addresses; this makes it impossible to send an email to <literal>jean</literal> or <literal>jean@machine</literal>, and requires using the full address instead, such as <literal>jean@machine.falcot.com</literal> or <literal>jean@falcot.com</literal>.
nb-NO: Regelen <literal>reject_unlisted_recipient</literal> avviser meldinger sendt til ikke-eksisterende lokale brukere, noe som gir mening. Til sist avslår <literal>reject_non_fqdn_recipient</literal>-regelen ikke-fullt-kvalifiserte adresser; dette gjør det umulig å sende e-post til <literal>jean</literal>, eller <literal>jean@machine</literal>, og krever bruk av hele adressen i stedet, som for eksempel <literal>jean@machine.falcot.com</literal>, eller <literal>jean@falcot.com</literal>.

en: The <literal>permit</literal> directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.
nb-NO: <literal>permit</literal>-direktiv ved slutten er ikke nødvendig. Men det kan være nyttig på slutten av en begrensningsliste for å gjøre forvalgt praksis eksplisitt.

en: Restrictions Associated with the <literal>DATA</literal> Command
nb-NO: Restriksjoner knyttet til <literal>DATA</literal>-kommandoen

en: <primary>email</primary><secondary>filtering on SMTP commands</secondary>
nb-NO: <primary>e-post</primary><secondary>filtering på SMTP-kommandoer</secondary>

en: The <literal>DATA</literal> command of SMTP is emitted before the contents of the message. It doesn't provide any information per se, apart from announcing what comes next. It can still be subjected to checks.
nb-NO: <literal>DATA</literal>-kommandoen til SMTP avgis før innholdet i meldingen. Den gir ikke noen informasjon per se (av seg selv), bortsett fra å annonsere hva som kommer etterpå. Den kan fortsatt være underlagt sjekk.

en: <literal>DATA</literal> checks
nb-NO: <literal>DATA</literal>-sjekk

en: The <literal>reject_unauth_pipelining</literal> directives causes the message to be rejected if the sending party sends a command before the reply to the previous command has been sent. This guards against a common optimization used by spammer robots, since they usually don't care a fig about replies and only focus on sending as many emails as possible in as short a time as possible.
nb-NO: Direktivene <literal>reject_unauth_pipelining</literal> fører til at meldingen blir avvist hvis avsenderen sender en kommando før svaret på forrige kommando har blitt sendt. Dette beskytter mot en vanlig optimalisering som brukes av spamroboter, siden de vanligvis ikke bryr seg det grann om svar, og bare fokuserer på å sende så mange e-poster som fort som mulig.

en: Applying Restrictions
nb-NO: Bruk av restriksjoner

en: Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the <literal>RCPT TO</literal> command by default.
nb-NO: Selv om ovennevnte kommandoene kontrollerer informasjon på ulike stadier av SMTP-utvekslingen, sender Postfix selve avslaget i et svar på <literal>RCPT TO</literal>-kommandoen som forvalg.

en: This means that even if the message is rejected due to an invalid <literal>EHLO</literal> command, Postfix knows the sender and the recipient when announcing the rejection. It can then log a more explicit message than it could if the transaction had been interrupted from the start. In addition, a number of SMTP clients do not expect failures on the early SMTP commands, and these clients will be less disturbed by this late rejection.
nb-NO: Dette betyr at selv om meldingen blir avvist på grunn av en ugyldig <literal>EHLO</literal>-kommando, kjenner Postfix avsenderen og mottakeren når avvisningen varsles. Den kan da logge et mer eksplisitt budskap enn om transaksjonen hadde blitt avbrutt fra starten. I tillegg trenger ikke en rekke SMTP-klienter å forvente feil med de tidlige SMTP-kommandoene, og disse klientene blir mindre forstyrret av dette ved denne senere avvisningen.

en: A final advantage to this choice is that the rules can accumulate information during the various stages of the SMTP exchange; this allows defining more fine-grained permissions, such as rejecting a non-local connection if it announces itself with a local sender.
nb-NO: En siste fordel ved dette valget er at reglene kan akkumulere informasjon fra de ulike stadiene i SMTP-utvekslingen. Dette tillater å definere mer finmaskede tillatelser, som for eksempel avvising av en ikke-lokal tilkobling hvis den melder seg med en lokal avsender.

en: The default behavior is controlled by the <literal>smtpd_delay_reject</literal> rule.
nb-NO: Forvalgt virkemåte styres av regelen <literal>smtpd_delay_reject</literal>.

en: Filtering Based on the Message Contents
nb-NO: Filtrering basert på meldingsinnholdet

en: <primary>email</primary><secondary>filtering on content inspection</secondary>
nb-NO: <primary>e-post</primary><secondary>filtering på innholdsinspeksjon</secondary>

en: <primary>email</primary><secondary>filtering on contents</secondary>
nb-NO: <primary>e-post</primary><secondary>filtrering på innhold</secondary>

en: The validation and restriction system would not be complete without a way to apply checks to the message contents. Postfix differentiates the checks applying to the email headers from those applying to the email body.
nb-NO: Gyldighets- og begrensningssystemet ville ikke være fullstendig uten å kunne sjekke meldingsinnholdet. Postfix skiller mellom sjekking av topptekster i e-postene - fra den som gjelder selve meldingskroppen.

en: Enabling content-based filters
nb-NO: Aktivering av innholdsbaserte filtre

en: Both files contain a list of regular expressions (commonly known as <emphasis>regexps</emphasis> or <emphasis>regexes</emphasis>) and associated actions to be triggered when the email headers (or body) match the expression.
nb-NO: Begge filer inneholder en liste med vanlige uttrykk (kjent som <emphasis>regexps</emphasis> eller <emphasis>regexes</emphasis>), og tilhørende tiltak som skal utløses når e-posthoder (eller kroppen) samsvarer med uttrykket.

en: <emphasis>QUICK LOOK</emphasis> Regexp tables
nb-NO: <emphasis>RASK TITT</emphasis> Regexp-tabeller

en: Example <filename>/etc/postfix/header_checks</filename> file
nb-NO: Eksempelfil <filename>/etc/postfix/header_checks</filename>

en: <emphasis>BACK TO BASICS</emphasis> Regular expression
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Regulært utrykk

en: The <emphasis>regular expression</emphasis> term (shortened to <emphasis>regexp</emphasis> or <emphasis>regex</emphasis>) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, <literal>foo|bar</literal> matches either “foo” or “bar”), sets of allowed characters (for instance, <literal>[0-9]</literal> means "any digit", and <literal>.</literal> — a dot — means "any character"), quantification (<literal>s?</literal> matches either <literal>s</literal> or the empty string, in other words 0 or 1 occurrence of <literal>s</literal>; <literal>s+</literal> matches one or more consecutive <literal>s</literal> characters; and so on). Parentheses allow grouping search results.
nb-NO: Betegnelsen <emphasis>regulært uttrykk</emphasis> (eng: regular expression) (forkortet til <emphasis>regexp</emphasis>, eller <emphasis>regex</emphasis>) refererer til en felles notasjon for å gi en beskrivelse av innholdet og/eller strukturen til en tegnstreng. Visse spesialtegn gjør det mulig å definere alternativer (for eksempel <literal>foo|bar</literal> treffer på enten «foo» eller «bar»), sett med tillatte tegn (for eksempel betyr <literal>[0-9]</literal> "hvilket som helst siffer", og <literal>.</literal> - et punktum - betyr "hvilket som helst tegn"), kvantifisering (<literal>s?</literal> samsvarer enten med <literal>s</literal>, eller den tomme strengen, med andre ord 0 eller 1 forekomsten av <literal>s</literal>; <literal>s+</literal> samsvarer med en eller flere påfølgende <literal>s</literal> tegn; og så videre). Parenteser tillater gruppering av søkeresultater.

en: The precise syntax of these expressions varies across the tools using them, but the basic features are similar. <ulink type="block" url="https://en.wikipedia.org/wiki/Regular_expression" />
nb-NO: Den presise syntaksen til disse uttrykkene varierer mellom de verktøyene som bruker dem, men de grunnleggende funksjonene er like. <ulink type="block" url="https://no.wikipedia.org/wiki/Regul%C3%A6rt_uttrykk" />

en: The first one checks the header mentioning the email software; if <literal>GOTO Sarbacane</literal> (a bulk email software) is found, the message is rejected. The second expression controls the message subject; if it mentions a virus notification, we can decide not to reject the message but to discard it immediately instead.
nb-NO: Den første sjekker toppteksten som viser til programvaren for e-postprogramvaren; hvis <literal>GOTO Sarbacane</literal> (en samling e-postprogramvare) blir funnet, blir meldingen avvist. Det andre uttrykket styrer meldingens emne; hvis det nevner et virusvarsel, kan vi bestemme oss for ikke å avvise meldingen, men straks å forkaste den istedenfor.

en: Using these filters is a double-edged sword, because it is easy to make the rules too generic and to lose legitimate emails as a consequence. In these cases, not only the messages will be lost, but their senders will get unwanted (and annoying) error messages.
nb-NO: Bruk av disse filterne er et tveegget sverd, fordi det er lett å gjøre reglene for allmenne, og som resultat miste legitim e-post. I disse tilfellene vil ikke bare meldingene gå tapt, men avsenderne får uønskede (og irriterende) feilmeldinger.

en: Setting Up <foreignphrase>greylisting</foreignphrase>
nb-NO: Oppsett av <foreignphrase>grålisting</foreignphrase>

en: <primary>greylisting</primary>
nb-NO: <primary>grålisting</primary>

en: <primary>email</primary><secondary>greylisting</secondary>
nb-NO: <primary>e-post</primary><secondary>grålisting</secondary>

en: Postfix doesn't provide greylisting natively, but there is a feature by which the decision to accept or reject a given message can be delegated to an external program. The <emphasis role="pkg">postgrey</emphasis> package contains just such a program, designed to interface with this access policy delegation service.
nb-NO: Postfix tilbyr ikke innebygd grålisting («greylisting»), men det er en funksjon, der beslutningen om å godta eller forkaste en gitt melding, kan delegeres til et eksternt program. Pakken <emphasis role="pkg">postgrey</emphasis> inneholder nettopp et slikt program, laget for å være bindeleddet til denne delegerte adgangspolitikktjenesten.

en: Once <emphasis role="pkg">postgrey</emphasis> is installed, it runs as a daemon and listens on port 10023. Postfix can then be configured to use it, by adding the <literal>check_policy_service</literal> parameter as an extra restriction:
nb-NO: Så snart <emphasis role="pkg">postgrey</emphasis> er installert, kjører den som bakgrunnsprosess, og lytter til port 10023. Postfix kan så settes opp til å bruke den ved å legge til <literal>check_policy_service</literal>-parameteret som ekstra begrensning:

en: The main disadvantage of greylisting is that legitimate messages get delayed, which is not always acceptable. It also increases the burden on servers that send many legitimate emails.
nb-NO: Den største ulempen med grålisting er at legitime meldinger bli forsinket, noe som ikke alltid er akseptabelt. Det øker også belastningen på tjenerne som sender mange legitime e-poster.

en: <emphasis>IN PRACTICE</emphasis> Shortcomings of greylisting
nb-NO: <emphasis>I PRAKSIS</emphasis> Svakhetene med grålisting

en: Theoretically, greylisting should only delay the first mail from a given sender to a given recipient, and the typical delay is in the order of minutes. Reality, however, can differ slightly. Some large ISPs use clusters of SMTP servers, and when a message is initially rejected, the server that retries the transmission may not be the same as the initial one. When that happens, the second server gets a temporary error message due to greylisting too, and so on; it may take several hours until transmission is attempted by a server that has already been involved, since SMTP servers usually increase the delay between retries at each failure.
nb-NO: Teoretisk bør grålisting kun forsinke den første e-posten fra en gitt sender til en gitt mottaker, og den typiske forsinkelsen er i størrelsesorden minutter. Dette kan i virkeligheten imidlertid avvike noe. Noen store ISP-er bruker klynger av SMTP-tjenere, og når en melding innledningsvis er avslått, er kanskje den tjeneren som prøver å gjenoppta overføringen ikke den samme som den opprinnelige. Når det skjer, får den andre tjeneren også en midlertidig feilmelding på grunn av grålisting, og så videre. Det kan ta flere timer før overføringen er forsøkt av en tjener som allerede har vært involvert, ettersom SMTP-tjenere ved hver feil vanligvis øker forsinkelsen.

en: As a consequence, the incoming IP address may vary in time even for a single sender. But it goes further: even the sender address can change. For instance, many mailing-list servers encode extra information in the sender address so as to be able to handle error messages (known as <emphasis>bounces</emphasis>). Each new message sent to a mailing-list may then need to go through greylisting, which means it has to be stored (temporarily) on the sender's server. For very large mailing-lists (with tens of thousands of subscribers), this can soon become a problem.
nb-NO: Som en konsekvens kan innkommende IP-adressen variere i tid, selv for én avsender. Men det går videre; selv avsenderadressen kan endres. For eksempel; mange e-postlistetjenere koder inn ekstra informasjon i avsenderadressen, for å være i stand til å håndtere feilmeldinger (kjent som <emphasis>bounces</emphasis>). Hver ny melding sendt til en adresseliste kan så trenge å gå gjennom grålisting, noe som betyr at den må lagres (midlertidig) på senderens tjener. For svært store e-postlister (med titusenvis av abonnenter), kan dette fort bli et problem.

en: To mitigate these drawbacks, Postgrey manages a whitelist of such sites, and messages emanating from them are immediately accepted without going through greylisting. This list can easily be adapted to local needs, since it is stored in the <filename>/etc/postgrey/whitelist_clients</filename> file.
nb-NO: For å redusere disse ulempene administrerer Postgrey en hviteliste med slike steder, og meldinger som kommer fra dem, blir umiddelbart akseptert uten å gjennomgå grålisting. Denne listen kan lett tilpasses de lokale behov, ettersom den er lagret i <filename>/etc/postgrey/whitelist_clients</filename>-filen.

en: <emphasis>GOING FURTHER</emphasis> Selective greylisting with <emphasis role="pkg">milter-greylist</emphasis>
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Selektiv grålisting med <emphasis role="pkg">milter-greylist</emphasis>

en: The drawbacks of greylisting can be mitigated by only using greylisting on the subset of clients that are already considered as probable sources of spam (because they are listed in a DNS blacklist). This is not possible with <emphasis role="pkg">postgrey</emphasis> but <emphasis role="pkg">milter-greylist</emphasis> can be used in such a way.
nb-NO: Ulempene med grålisting kan reduseres ved å kun bruke grålisting på undergruppen av klienter som allerede regnes som sannsynlige kilder til søppelpost (fordi de er oppført i en DNS-svarteliste). Dette er ikke mulig med <emphasis role="pkg">postgrey</emphasis> men <emphasis role="pkg">milter-greylist</emphasis> kan anvendes på en slik måte.

en: In that scenario, since DNS blacklists never triggers a definitive rejection, it becomes reasonable to use aggressive blacklists, including those listing all dynamic IP addresses from ISP clients (such as <literal>pbl.spamhaus.org</literal> or <literal>dul.dnsbl.sorbs.net</literal>).
nb-NO: I sådant fall, ettersom DNS-svartelister aldri utløser en endelig avvisning, blir det naturlig å bruke aggressive svartelister, medregnet de som viser alle dynamiske IP-adresser fra ISP-klienter (for eksempel <literal>pbl.spamhaus.org</literal>, eller <literal>dul.dnsbl.sorbs.net</literal>).

en: Since <emphasis role="pkg">milter-greylist</emphasis> uses Sendmail's milter interface, the postfix side of its configuration is limited to “<literal>smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock</literal>”. The <citerefentry><refentrytitle>greylist.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> manual page documents <filename>/etc/milter-greylist/greylist.conf</filename> and the numerous ways to configure milter-greylist. You will also have to edit <filename>/etc/default/milter-greylist</filename> to actually enable the service.
nb-NO: Siden <emphasis role="pkg"> milter-greylist</emphasis> bruker Sendmails sitt milter-grensesnitt, er Postfix-siden av oppsettet begrenset til «<literal>smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock</literal>». Manualsiden <citerefentry><refentrytitle>greylist.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> dokumenterer <filename>/etc/milter-greylist/greylist.conf</filename>, og de utallige måter å sette opp milter-grålisting på. Du vil også måtte redigere <filename>/etc/default/milter-greylist</filename> for faktisk å aktivere tjenesten.

en: Customizing Filters Based On the Recipient
nb-NO: Tilpasning av filtre basert på mottager

en: <primary>email</primary><secondary>custom restriction classes</secondary>
nb-NO: <primary>e-post</primary><secondary>tilpassede begresningsklasser</secondary>

en: <xref linkend="sect.restrictions-for-receiving-and-sending" /> and <xref linkend="sect.setting-up-greylisting" /> reviewed many of the possible restrictions. They all have their use in limiting the amount of received spam, but they also all have their drawbacks. It is therefore more and more common to customize the set of filters depending on the recipient. At Falcot Corp, greylisting is interesting for most users, but it hinders the work of some users who need low latency in their emails (such as the technical support service). Similarly, the commercial service sometimes has problems receiving emails from some Asian providers who may be listed in blacklists; this service asked for a non-filtered address so as to be able to correspond.
nb-NO: <xref linkend="sect.restrictions-for-receiving-and-sending" /> og <xref linkend="sect.setting-up-greylisting" /> gjennomgikk mange av de mulige restriksjonene. De har alle sin nytte ved å begrense mengden mottatt søppelpost, men har alle også sine ulemper. Det er derfor mer og mer vanlig å tilpasse filtrene til mottageren. I Falcot Corp er grålisting interessant for de fleste brukere, men det hindrer arbeidet til noen brukere som har behov for korte forsinkelser for sine e-poster (som for eksempel teknisk brukerstøttetjeneste). Tilsvarende, den kommersielle tjenesten har noen ganger problemer med å motta e-post fra noen asiatiske leverandører som kan være oppført i svartelister; denne tjenesten trenger en ikke-filtrert adresse for å kunne utveksle e-poster.

en: Postfix provides such a customization of filters with a “restriction class” concept. The classes are declared in the <literal>smtpd_restriction_classes</literal> parameter, and defined the same way as <literal>smtpd_recipient_restrictions</literal>. The <literal>check_recipient_access</literal> directive then defines a table mapping a given recipient to the appropriate set of restrictions.
nb-NO: Postfix gir en slik filtertilpasning med «restriction class»-konseptet. Klassene deklareres i <literal>smtpd_restriction_classes</literal>-parametret, og defineres på samme måten som <literal>smtpd_recipient_restrictions</literal>. Direktivet <literal>check_recipient_access</literal> definerer deretter en tabell som legger en gitt mottaker til det riktige settet restriksjoner.

en: Defining restriction classes in <filename>main.cf</filename>
nb-NO: Definering av begrensningsklasser i <filename>main.cf</filename>

en: The <filename>/etc/postfix/recipient_access</filename> file
nb-NO: Filen <filename>/etc/postfix/recipient_access</filename>

en: 
    # Unfiltered addresses
    postmaster@falcot.com  permissive
    support@falcot.com     permissive
    sales-asia@falcot.com  permissive
    
    # Aggressive filtering for some privileged users
    joe@falcot.com         aggressive
    
    # Special rule for the mailing-list manager
    sympa@falcot.com       reject_unverified_sender
    
    # Greylisting by default
    falcot.com             greylisting
nb-NO: 
    # Adresser som ikke filtreres
    postmaster@falcot.com  permissive
    support@falcot.com     permissive
    sales-asia@falcot.com  permissive
    
    # Aggressiv filtrering for noen privilegerte brukere
    joe@falcot.com         aggressive
    
    # Spesialregel for den som styrer e-postlisten
    sympa@falcot.com       reject_unverified_sender
    
    # Grålisting som forvalg
    falcot.com             greylisting

en: <primary>email</primary><secondary>virus scanning</secondary>
nb-NO: <primary>e-post</primary><secondary>virus-skanning</secondary>

en: <emphasis>SECURITY</emphasis> Controversial Discussion of Anti-Virus Software
nb-NO: <emphasis>SIKKERHET</emphasis> Kontrovers rundt antivirus-programvare

en: The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).
nb-NO: Bruken av virusskannere, eller såkalt antivirusprogramvare, er kontroversielt. Det er vanligvis et tidsgap mellom utgivelsen av noen deler av skadeprogramvare og tillegget med deteksjonsregler til antivirusdatabasen. I løpet av dette gapet er det ingen programvarebasert beskyttelse. Videre krever bruken ofte å kjøre ekstra programvare, for eksempel for å dekomprimere arkiver og skanne alle typer kjørbare filer, noe som drastisk øker utnyttelsespotensialet til selve antivirusprogramvaren. Bruk av slike programvareløsninger kan derfor aldri erstatte bevissthetskampanjer og enkle atferdsregler (som aldri å åpne uønskede sendte vedlegg, etc.).

en: <primary>antivirus</primary><secondary>controversy</secondary>
nb-NO: <primary>antivirus</primary><secondary>kontrovers</secondary>

en: The Falcot administrators selected <command>clamav</command> from the homonymous package.
nb-NO: Falcot- administratorene valgte <command>clamav</command> fra homonymous-pakken.

en: The task of interfacing between antivirus and the email server goes to <command>clamav-milter</command>. A <emphasis>milter</emphasis> (short for <emphasis>mail filter</emphasis>) is a filtering program specially designed to interface with email servers. A milter uses a standard application programming interface (API) that provides much better performance than filters external to the email servers. Milters were initially introduced by <emphasis>Sendmail</emphasis>, but <emphasis>Postfix</emphasis> soon followed suit.
nb-NO: Oppgaven med å koble sammen antivirus og e-posttjeneren legges til <command>clamav-milter</command>. Et <emphasis>milter</emphasis> (kort for <emphasis>e-postfilter (mail filter)</emphasis>) er et filterprogram spesielt utviklet for å kommunisere med e-posttjenere. Et milter bruker et standard programmeringsgrensesnitt (API) som gir mye bedre ytelse enn eksterne e-posttjenerfiltre. Milters ble først introdusert av <emphasis>Sendmail</emphasis>, men <emphasis>Postfix</emphasis> kom snart etter.

en: <emphasis>QUICK LOOK</emphasis> A milter for Spamassassin
nb-NO: <emphasis>RASK TITT</emphasis> Et milter for Spamassassin

en: The <emphasis role="pkg">spamass-milter</emphasis> package provides a milter based on <emphasis>SpamAssassin</emphasis>, the famous unsolicited email detector. It can be used to flag messages as probable spams (by adding an extra header) and/or to reject the messages altogether if their “spamminess” score goes beyond a given threshold.
nb-NO: Pakken <emphasis role="pkg">spamass-milter</emphasis> gir et milter basert på <emphasis>SpamAssassin</emphasis>, den berømte detektoren for uønsket e-post. Den kan brukes til å flagge meldinger som er mulig søppelpost (ved å legge til en ekstra topptekst) og/eller for helt å avvise meldinger hvis søppelpostantagelsene («spaminess» -poengsum) overgår en gitt terskel.

en: Once the <emphasis role="pkg">clamav-milter</emphasis> package is installed, the milter should be reconfigured to run on a TCP port rather than on the default named socket. This can be achieved with <command>dpkg-reconfigure clamav-milter</command>. When prompted for the “Communication interface with Sendmail”, answer “<literal>inet:10002@127.0.0.1</literal>”.
nb-NO: Så snart pakken <emphasis role="pkg">clamav-milter</emphasis> er installert, skal milter settes opp til å kjøre på en TCP-port i stedet for på forvalget som heter socket. Dette kan oppnås med <command>dpkg-reconfigure clamav-milter</command>. Når du blir bedt om «Kommunikasjonsgrensesnitt med Sendmail», svar «<literal>inet:10002@127.0.0.1</literal>».

en: <emphasis>NOTE</emphasis> Real TCP port vs named socket
nb-NO: <emphasis>MERK</emphasis> Ekte TCP-port vs navngitt socket

en: The reason why we use a real TCP port rather than the named socket is that the postfix daemons often run chrooted and do not have access to the directory hosting the named socket. You could also decide to keep using a named socket and pick a location within the chroot (<filename>/var/spool/postfix/</filename>).
nb-NO: Grunnen til at en ekte TCP-port brukes i stedet for den navngitte socket-en, er at postfix-bakgrunnsprosesser ofte kjører chroot, og ikke har tilgang til katalogen som er vertskap for den navngitte socket-en. Du kan også velge å fortsette å bruke en navngitt socket, og velge et sted i chroot (<filename>/var/spool/postfix/</filename>).

en: The standard ClamAV configuration fits most situations, but some important parameters can still be customized with <command>dpkg-reconfigure clamav-base</command>.
nb-NO: Forvalgt ClamAV-oppsett passer til de fleste situasjoner, men noen viktige parametre kan fortsatt tilpasses med <command>dpkg-reconfigure clamav-base</command>.

en: The last step involves telling Postfix to use the recently-configured filter. This is a simple matter of adding the following directive to <filename>/etc/postfix/main.cf</filename>:
nb-NO: Det siste trinnet er å be Postfix om å bruke det nylig oppsatte filteret. Det er en enkel sak å legge følgende direktiv til <filename>/etc/postfix/main.cf</filename>:

en: 
    # Virus check with clamav-milter
    smtpd_milters = inet:[127.0.0.1]:10002
nb-NO: 
    # Virus-sjekk med ClamAV-milter
    smtpd_milters = inet:[127.0.0.1]:10002

en: If the antivirus causes problems, this line can be commented out, and <command>systemctl reload postfix</command> should be run so that this change is taken into account.
nb-NO: Hvis antivirusprogrammet skaper problemer, kan denne linjen kommenteres ut, og <command>systemctl reload postfix</command> skal kjøres slik at denne endringen er tatt hensyn til.

en: <emphasis>IN PRACTICE</emphasis> Testing the antivirus
nb-NO: <emphasis>I PRAKSIS</emphasis> Testing av antivirus

en: Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the <filename>eicar.com</filename> (or <filename>eicar.com.zip</filename>) file, which can be downloaded online: <ulink type="block" url="https://2016.eicar.org/86-0-Intended-use.html" />
nb-NO: Når antivirus er satt opp, skal det testes om oppførselen er korrekt. Den enkleste måten å gjøre det på, er å sende en test-e-post med et vedlegg som inneholder <filename>eicar.com</filename> (eller <filename>eicar.com.zip</filename>)-filen, som kan lastes ned fra nettet: <ulink type="block" url="https://2016.eicar.org/86-0-Intended-use.html" />

en: This file is not a true virus, but a test file that all antivirus software on the market diagnose as a virus to allow checking installations.
nb-NO: Denne filen er ikke et ekte virus, men en testfil som all antivirusprogramvare på markedet diagnostiserer som et virus, for å tillate sjekking av installasjoner.

en: All messages handled by Postfix now go through the antivirus filter.
nb-NO: Alle meldinger som Postfix håndterer, går nå igjennom antivirusfilteret.

en: Fighting Spam with SPF, DKIM and DMARC
nb-NO: Kamp mot søppelpost med SPF, DKIM og DMARC

en: The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.
nb-NO: Det høye antallet uønskede e-poster sendt hver dag førte til opprettelsen av flere standarder, som tar sikte på å validere, at den sendende verten av en e-post er autorisert og at e-posten ikke har blitt tuklet med. Følgende systemer er alle DNS-baserte, og krever at administratorene ikke bare har kontroll over e-posttjeneren, men også over DNS for det aktuelle domenet.

en: <emphasis>CAUTION</emphasis> Controversial Discussion
nb-NO: <emphasis>VÆR VARSOM</emphasis> Kontroversiell diskusjon

en: Integrating the Sender Policy Framework (SPF)
nb-NO: Integrasjon av forsendelsespraksisrammeverk (SPF)

en: The Sender Policy Framework (<acronym>SPF</acronym>) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at: <ulink type="block" url="http://www.open-spf.org/SPF_Record_Syntax" /> <ulink type="block" url="https://tools.ietf.org/html/rfc7208" /> <ulink type="block" url="https://en.wikipedia.org/wiki/Sender_Policy_Framework" />
nb-NO: Forsendelsespraksisrammeverk (<acronym>SPF</acronym>) brukes til å validere om en bestemt e-posttjener har lov til å sende e-post for et gitt domene. Det blir for det meste satt opp via DNS. Syntaksen for oppføringen som skal gjøres, forklares i detalj på: <ulink type="block" url="http://www.open-spf.org/SPF_Record_Syntax" /> <ulink type="block" url="https://tools.ietf.org/html/rfc7208" /> <ulink type="block" url="https://sv.wikipedia.org/wiki/Sender_Policy_Framework" />

en: Let's take a quick look at the <literal>falcot.org</literal> entry.
nb-NO: La oss ta en kjapp titt på <literal>falcot.org</literal>-oppføringen.

en: It states that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.
nb-NO: Den sier at IP-adressen til avsenderen må samsvare med A-oppføringen for avsenderdomenet, eller må være oppført som en av Mail Exchange Resource Records for gjeldende domene, eller må være en av de tre nevnte IPv4-adressene. Alle andre verter skal merkes til å forby forsendelse av e-post til avsenderdomenet. Sistnevnte kalles en «myk feil» og er ment brukt til å sette et merke på e-posten, men fortsatt akseptere den.

en: The <command>postfix</command> mail server can check the SPF record for incoming emails using the <emphasis role="pkg">postfix-policyd-spf-python</emphasis> package, a policy agent written in Python. The file <filename>/usr/share/doc/postfix-policyd-spf-python/README.Debian</filename> describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.
nb-NO: <command>postfix</command> e-posttjeneren kan sjekke SPF-oppføringen for innkommende e-postmeldinger ved hjelp av <emphasis role="pkg">postfix-policyd-spf-python</emphasis>-pakken, en regelagent skrevet i Python. Filen <filename>/usr/share/doc/postfix-policyd-spf-python/README.Debian</filename> beskriver de nødvendige trinnene for å integrere agenten i postfix, så vi vil ikke repetere det her.

en: The configuration is done in the file <filename>/etc/postfix-policyd-spf-python/policyd-spf.conf</filename>, which is fully documented in <citerefentry><refentrytitle>policyd-spf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> and <filename>/usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz</filename>. The main configuration parameters are <literal>HELO_reject</literal> and <literal>Mail_From_reject</literal>, which configure if emails should be rejected (<literal>Fail</literal>) or accepted with a header being appended (<literal>False</literal>), if checks fail. The latter is often useful, when the message is further processed by a spam filter.
nb-NO: Oppsettet gjøres i filen <filename>/etc/postfix-policyd-spf-python/policyd-spf.conf</filename>, som er dokumentert i sin helhet i <citerefentry><refentrytitle>policyd-spf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> og <filename>/usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz</filename>. Hovedoppsettsparameterne er <literal>HELO_reject</literal> og <literal>Mail_From_reject</literal>, som setter opp om e-postmeldinger skal avvises (<literal>Fail</literal>) eller akseptert med en topptekst som legges til (<literal>False</literal>), hvis kontroller mislykkes. Sistnevnte er ofte nyttig, når meldingen behandles videre av et søppelpostfilter.

en: If the result is intended to be used by <emphasis role="pkg">opendmarc</emphasis> (<xref linkend="sect.dmarc" />), then <literal>Header_Type</literal> must be set to <literal>AR</literal>.
nb-NO: Hvis resultatet er ment å brukes av <emphasis role="pkg">opendmarc</emphasis> (<xref linkend="sect.dmarc" />), må <literal>Header_Type</literal> settes til <literal>AR</literal>.

en: Note that <emphasis role="pkg">spamassassin</emphasis> contains a plugin to check the SPF record.
nb-NO: Merk at <emphasis role="pkg">spamassassin</emphasis> inneholder et programtillegg for å sjekke SPF-oppføringen.

en: Integrating DomainKeys (DKIM) Signing and Checking
nb-NO: Integrasjon av DomainKeys (DKIM) Signering og sjekking

en: The Domain Keys Identified Mail (<acronym>DKIM</acronym>) standard is a sender authentication system. The mail transport agent, here <command>postfix</command>, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records. <ulink type="block" url="http://dkim.org/" />
nb-NO: Domain Keys Identified Mail (<acronym>DKIM</acronym>)-standarden er et avsenderautentiseringssystem. Posttransportagenten, her <command>postfix</command>, legger til en digital signatur tilknyttet domenenavnet til hodet på en utgående e-postmeldinger. Den mottagende part kan validere meldingstekst- og hodefeltene ved å kontrollere signaturen mot en offentlig nøkkel, som hentes fra avsenderens DNS-oppføringer. <ulink type="block" url="http://dkim.org/" />

en: The necessary tools are shipped with the <emphasis role="pkg">opendkim</emphasis> and <emphasis role="pkg">opendkim-tools</emphasis> packages.
nb-NO: De nødvendige programmene er tilgjengelig i <emphasis role="pkg">opendkim</emphasis> og <emphasis role="pkg">opendkim-tools</emphasis>-pakkene.

en: <emphasis>CAUTION</emphasis> Mailing List Software and DKIM
nb-NO: <emphasis>VÆR VARSOM</emphasis> E-postlisteprogramvare og DKIM

en: Mailing list managers often rewrite some email headers, thus leading to invalid DKIM signatures. Even using a <literal>relaxed</literal> canonicalization does not always prevent this from happening. So the administrators must pay close attention to the mail severs log files to identify such issues. Otherwise such emails might be flagged as spam and might get rejected.
nb-NO: E-postlistehådterere skriver ofte om noen e-posthoder, noe som fører til ugyldige DKIM-signaturer. Selv en <literal>relaxed</literal>-kanonisering forhindrer ikke alltid dette fra å skje. Så administratorene må være oppmerksom på e-postens tjenerloggfiler for å identifisere slike problemer. Ellers kan slike e-postmeldinger bli flagget som søppelpost og følgelig avvist.

en: First the private key must be created using the command <command>opendkim-genkey -s <replaceable>SELECTOR</replaceable> -d <replaceable>DOMAIN</replaceable></command>. <replaceable>SELECTOR</replaceable> must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.
nb-NO: Først må den private nøkkelen opprettes ved hjelp av kommandoen <command>opendkim-genkey -s <replaceable>SELECTOR</replaceable> -d <replaceable>DOMAIN</replaceable></command>. <replaceable> SELECTOR</replaceable> som må være et unikt navn for nøkkelen. Det kan være så enkelt som "e-post", eller opprettelsesdatoen, hvis du planlegger å rotere nøkler.

en: Create a private key for signing E-Mails from falcot.com
nb-NO: Opprettelse av privat nøkkel for signering av e-post fra falcot.com

en: This will create the files <filename>/etc/dkimkeys/mail.private</filename> and <filename>/etc/dkimkeys/mail.txt</filename> and set the appropriate ownership. The first file contains the private key, and the latter the public key that needs to be added to the DNS:
nb-NO: Dette vil opprette filene <filename>/etc/dkimkeys/mail.private</filename> og <filename>/etc/dkimkeys/mail.txt</filename> og sette riktig eierskap. Den første filen inneholder den private nøkkelen. Sistnevnte inneholder den offentlige nøkkelen, som må legges til i DNS:

en: The <emphasis role="pkg">opendkim</emphasis> package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option <command>-b 1024</command> to chose a smaller keysize. If <command>opendkim-testkey</command> succeeds, the entry has been successfully set up. The syntax of the entry is explained here: <ulink type="block" url="https://tools.ietf.org/html/rfc6376" /> <ulink type="block" url="https://en.wikipedia.org/wiki/DKIM" />
nb-NO: Forvalget for <emphasis role="pkg">opendkim</emphasis>-pakken i Debian er 2048-biters nøkkelstørrelse. Dessverre kan noen DNS-tjenere kun håndtere tekstoppføringer med maksimal lengde på 255 tegn, som overskrides av den valgte forvalgsnøkkelstørrelsen. I dette tilfellet bruker du alternativet <command>-b 1024</command> for å velge en mindre nøkkelstørrelse. Hvis <command>opendkim-testkey</command> lykkes, er oppføringen opprettet. Syntaksen for oppføringen er forklart her: <ulink type="block" url="https://tools.ietf.org/html/rfc6376" /> <ulink type="block" url="https://sv.wikipedia.org/wiki/DomainKeys_Identified_Mail" />

en: To configure <emphasis role="pkg">opendkim</emphasis>, <literal>SOCKET</literal> and <literal>RUNDIR</literal> must be chosen in <filename>/etc/default/opendkim</filename>. Please note that <literal>SOCKET</literal> must be accessible from <literal>postfix</literal> in its chrooted environment. The further configuration is done in <filename>/etc/opendkim.conf</filename>. The following is a configuration excerpt, which makes sure that the <literal>Domain</literal> "falcot.com" and all subdomains (<literal>SubDomain</literal>) are signed by the <literal>Selector</literal> "mail" and the single private key (<literal>KeyFile</literal>) <filename>/etc/dkimkeys/mail.private</filename>. The "relaxed" <literal>Canonicalization</literal> for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") <literal>Mode</literal>. If a signature fails to validate (<literal>On-BadSignature</literal>), the mail should be quarantined ("q").
nb-NO: Hvis du vil sette opp <emphasis role="pkg">opendkim</emphasis>, må <literal>SOCKET</literal> og <literal>RUNDIR</literal> velges i <filename>/etc/default/opendkim</filename>. Vær oppmerksom på at <literal>SOCKET</literal> må være tilgjengelig fra <literal>postfix</literal> i sitt chroot-ede miljø. Det videre oppsettet gjøres i <filename>/etc/opendkim.conf</filename>. Følgende er et utdrag av oppsettet, som sørger for at <literal>Domain</literal> "falcot.com" og alle underdomener (<literal>SubDomain</literal>) er signert av <literal>Selector</literal> "mail" og den enkle private nøkkelen (<literal>KeyFile</literal>) <filename>/etc/dkimkeys/mail.private</filename>. Den "avslappete" <literal>Canonicalization</literal> for både overskriften og kroppen tåler mild endring (for eksempel av en postlistelisteprogramvare). Filteret kjører både ved signering ("s") og verifisering ("v") <literal>Mode</literal>. Hvis en signatur ikke valideres (<literal>On-BadSignature</literal>), skal e-posten settes i karantene ("q").

en: It is also possible to use multiple selectors/keys (<literal>KeyTable</literal>), domains (<literal>SigningTable</literal>) and to specify internal or trusted hosts (<literal>InternalHosts</literal>, <literal>ExternalIgnoreList</literal>), which may send mail through the server as one of the signing domains without credentials.
nb-NO: Det er også mulig å bruke flere velgere/nøkler (<literal>KeyTable</literal>), domener (<literal>SigningTable</literal>) og angi interne eller klarerte verter (<literal>InternalHosts</literal>, <literal>ExternalIgnoreList</literal>), som kan sende e-post via tjeneren som ett av signeringsdomenene uten legitimering.

en: The following directives in <filename>/etc/postfix/main.cf</filename> make <literal>postfix</literal> use the filter:
nb-NO: Følgende direktiver i <filename>/etc/postfix/main.cf</filename> sørger for at <literal>postfix</literal> bruker filteret:

en: To differentiate signing and verification it is sometimes more useful to add the directives to the services in <filename>/etc/postfix/master.cf</filename> instead.
nb-NO: For å differensiere signering og verifisering er det noen ganger mer nyttig å legge til direktivene til i tjenestene i <filename>/etc/postfix/master.cf</filename> i stedet.

en: More information is available in the <filename>/usr/share/doc/opendkim/</filename> directory and the manual pages <citerefentry><refentrytitle>opendkim</refentrytitle> <manvolnum>8</manvolnum></citerefentry> and <citerefentry><refentrytitle>opendkim.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>.
nb-NO: Mer info er tilgjengelig i katalogen <filename>/usr/share/doc/opendkim/</filename> og i manualsidene <citerefentry><refentrytitle>opendkim</refentrytitle> <manvolnum>. 8</manvolnum></citerefentry> og <citerefentry><refentrytitle>opendkim.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>.

en: Note that <emphasis role="pkg">spamassassin</emphasis> contains a plugin to check the DKIM record.
nb-NO: Merk at <emphasis role="pkg">spamassassin</emphasis> inneholder et programtillegg for å sjekke SPF-oppføringen.

en: Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)
nb-NO: Integrasjon av Domain-based Message Authentication, Reporting og Conformance (DMARC)

en: The Domain-based Message Authentication, Reporting and Conformance (<acronym>DMARC</acronym>) standard can be used to define a DNS TXT entry with the name <literal>_dmarc</literal> and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF. <ulink type="block" url="https://dmarc.org/overview/" />
nb-NO: Standarden Domain-based Message Authentication, Reporting and Conformance (<acronym>DMARC</acronym>) kan brukes til å definere en DNS TXT-oppføring med navnet <literal>_dmarc</literal> og informasjon om handlingen som bør utføres når e-postmeldinger, som inneholder domenet ditt som avsendervert, ikke klarer å validere ved hjelp av DKIM og SPF. <ulink type="block" url="https://dmarc.org/overview/" />

en: Let's have a look at the entries of two large providers:
nb-NO: La oss se på oppføringene til to store leverandører:

en: Yahoo has a strict policy to <literal>reject</literal> all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (<literal>p=none</literal>). For subdomains they should be marked as spam (<literal>sp=quarantine</literal>). The addresses given in the <literal>rua</literal> key can be used to send aggregated DMARC reports to. The full syntax is explained here: <ulink type="block" url="https://tools.ietf.org/html/rfc7489" /> <ulink type="block" url="https://en.wikipedia.org/wiki/DMARC" />
nb-NO: Yahoo har en streng policy med å <literal>avvise</literal> alle e-postmeldinger som utgir seg for å bli sendt fra en Yahoo-konto, men mangler eller mislykkes med DKIM og SPF sjekker. Google Mail (Gmail) har en svært avslappet policy, der slike meldinger fra hoveddomenet fortsatt skal aksepteres (<literal>p=none</literal>). For underdomener bør de merkes som spam (<literal>sp=quarantine</literal>). Adressene som er oppgitt i <literal>rua</literal>-nøkkelen, kan brukes til å sende aggregerte DMARC-rapporter også. Den fullstendige syntaksen er forklart her: <ulink type="block" url="https://tools.ietf.org/html/rfc7489" /> <ulink type="block" url="https://en.wikipedia.org/wiki/DMARC" />

en: The <command>postfix</command> mail server can use this information too. The <emphasis role="pkg">opendmarc</emphasis> package contains the necessary milter. Similar to <emphasis role="pkg">opendkim</emphasis> <literal>SOCKET</literal> and <literal>RUNDIR</literal> must be chosen in <filename>/etc/default/opendmarc</filename> (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file <filename>/etc/opendmarc.conf</filename> contains detailed comments and is also explained in <citerefentry><refentrytitle>opendmarc.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>. By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use <literal>RejectFailures true</literal>.
nb-NO: E-posttjeneren <command>postfix</command> kan også bruke denne informasjonen. Pakken <emphasis role="pkg">opendmarc</emphasis> inneholder det nødvendige e-postfilter. I likhet med for <emphasis role="pkg">opendkim</emphasis> må <literal>SOCKET</literal> og <literal>RUNDIR</literal> velges i <filename>/etc/default/opendmarc</filename> (for Unix sockets må du sørge for at de er inne i postfix chrootet for å bli funnet). Oppsettfilen <filename>/etc/opendmarc.conf</filename> inneholder detaljerte kommentarer og er også forklart i <citerefentry><refentrytitle>opendmarc.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>. I utgangspunktet avvises ikke e-postmeldinger som ikke klarer DMARC-valideringen, men flagges, ved å legge til et passende hodefelt. Hvis du vil endre dette, kan du bruke <literal>RejectFailures true</literal>.

en: The milter is then added to <literal>smtpd_milters</literal> and <literal>non_smtpd_milters</literal>. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in <filename>/etc/postfix/main.cf</filename> looks like this:
nb-NO: E-postfilteret blir deretter lagt til <literal>smtpd_milters</literal> og <literal>non_smtpd_milters</literal>. Hvis vi satte opp opendkim og opendmarc e-postfiltreret til å kjøre på porter 12345 og 54321, ser oppføringen i <filename>/etc/postfix/main.cf</filename> slik ut:

en: The milter can also be selectively applied to a service in <filename>/etc/postfix/master.cf</filename> instead.
nb-NO: Milteret (e-postfilteret) kan også selektivt brukes på en tjeneste i <filename>/etc/postfix/master.cf</filename> i stedet.

en: Authenticated SMTP
nb-NO: Godkjent SMTP

en: Being able to send emails requires an SMTP server to be reachable; it also requires said SMTP server to send emails through it. For roaming users, this may need regularly changing the configuration of the SMTP client, since Falcot's SMTP server rejects messages coming from IP addresses apparently not belonging to the company. Two solutions exist: either the roaming user installs an SMTP server on their computer, or they still use the company server with some means of authenticating as an employee. The former solution is not recommended since the computer won't be permanently connected, and it won't be able to retry sending messages in case of problems; we will focus on the latter solution.
nb-NO: Å kunne sende e-poster krever tilgang på en SMTP-tjener; det krever også nevnte SMTP-tjener for å sende e-post igjennom den. For flyttbare enheter kan det trenges jevnlig endring av oppsettet til SMTP-klienten, ettersom Falcots SMTP-tjener avviser meldinger som kommer fra IP-adresser som tilsynelatende ikke tilhører selskapet. To løsninger finnes: Enten installerer brukeren en SMTP-tjener på datamaskinen sin, eller de fortsetter å bruke selskapets tjener med noen metoder for å autentisere seg som en ansatt. Den første løsningen er ikke anbefalt siden maskinen ikke vil være permanent tilkoblet, og ikke være i stand til igjen å prøve å sende meldinger i tilfelle problemer. Vi vil fokusere på sistnevnte løsning.

en: SMTP authentication in Postfix relies on SASL (<emphasis>Simple Authentication and Security Layer</emphasis>). It requires installing the <emphasis role="pkg">libsasl2-modules</emphasis> and <emphasis role="pkg">sasl2-bin</emphasis> packages, then registering a password in the SASL database for each user that needs authenticating on the SMTP server. This is done with the <command>saslpasswd2</command> command, which takes several parameters. The <literal>-u</literal> option defines the authentication domain, which must match the <literal>smtpd_sasl_local_domain</literal> parameter in the Postfix configuration. The <literal>-c</literal> option allows creating a user, and <literal>-f</literal> allows specifying the file to use if the SASL database needs to be stored at a different location than the default (<filename>/etc/sasldb2</filename>).
nb-NO: SMTP-autentisering i Postfix hviler på SASL (<emphasis>Simple Authentication and Security Layer</emphasis>). Det krever installasjon av <emphasis role="pkg">libsasl2-modules</emphasis> og <emphasis role="pkg">sasl2-bin</emphasis>-pakker, deretter å registrere et passord i SASL-databasen for hver bruker som trenger autentisering på SMTP-tjeneren. Dette gjøres med <command>saslpasswd2</command>-kommandoen, som krever flere parametre. Valget <literal>-u</literal> definerer godkjenningsdomenet, som må samsvare med <literal>smtpd_sasl_local_domain</literal>-parameteret i Postfix-oppsettet. Valget <literal>-c</literal> tillater å lage en bruker, og <literal>-f</literal> kan spesifisere filen som skal brukes hvis SASL-databasen må lagres på et annet sted enn opprinnelig (<filename>/etc/sasldb2</filename>).

en: 
    <computeroutput># </computeroutput><userinput>saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean</userinput>
    <computeroutput>[... type jean's password twice ...]</computeroutput>
nb-NO: 
    <computeroutput># </computeroutput><userinput>saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean</userinput>
    <computeroutput>[... skriv inn passordet til jean to ganger ...]</computeroutput>

en: Note that the SASL database was created in Postfix's directory. In order to ensure consistency, we also turn <filename>/etc/sasldb2</filename> into a symbolic link pointing at the database used by Postfix, with the <command>ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2</command> command.
nb-NO: Merk at SASL-databasen ble opprettet i Postfix-katalogen. For å sikre sammenhengen, omgjør vi også <filename>/etc/sasldb2</filename> til en symbolsk lenke som peker på databasen som brukes av Postfix, med <command>ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2</command>-kommandoen.

en: Now we need to configure Postfix to use SASL. First the <literal>postfix</literal> user needs to be added to the <literal>sasl</literal> group, so that it can access the SASL account database. A few new parameters are also needed to enable SASL, and the <literal>smtpd_recipient_restrictions</literal> parameter needs to be configured to allow SASL-authenticated clients to send emails freely.
nb-NO: Nå trenger vi å sette opp Postfix til å bruke SASL. Først må <literal>postfix</literal>-brukeren legges til <literal>sasl</literal>-gruppen, slik at den kan få tilgang til SASL-kontoens database. Et par nye parametere må også til for å aktivere SASL, og <literal>smtpd_recipient_restrictions</literal>-parameteret må settes opp til å tillate at SASL-godkjente klienter fritt kan sende e-post.

en: Enabling SASL in <filename>/etc/postfix/main.cf</filename>
nb-NO: Oppsett av SASL i <filename>/etc/postfix/main.cf</filename>

en: It is usually a good idea to not send passwords over an unencrypted connection. <emphasis>Postfix</emphasis> allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the <filename>/etc/postfix/master.cf</filename> file. To turn off authentication at all for port 25 (<literal>smtpd</literal> service) add the following directive:
nb-NO: Det er vanligvis en god idé å ikke sende passord over en ukryptert tilkobling. <emphasis> Postfix</emphasis> gjør det mulig å bruke separat oppsett for hver port (tjeneste) den kjører på. Alle disse kan settes opp med forskjellige regler og direktiver i filen <filename>/etc/postfix/master.cf</filename>. Hvis du vil deaktivere godkjenning i det hele tatt for port 25 (<literal>smtpd</literal>-tjenesten), legger du til følgende direktiv:

en: <emphasis>EXTRA</emphasis> Authenticated SMTP client
nb-NO: <emphasis>EKSTRA</emphasis> Autentisert SMTP-klient

en: Most email clients are able to authenticate to an SMTP server before sending outgoing messages, and using that feature is a simple matter of configuring the appropriate parameters. If the client in use does not provide that feature, the workaround is to use a local Postfix server and configure it to relay email via the remote SMTP server. In this case, the local Postfix itself will be the client that authenticates with SASL. Here are the required parameters:
nb-NO: De fleste e-postklienter er i stand til å autentisere til en SMTP-tjener før den sender utgående meldinger, og ved hjelp av denne funksjonen er det en enkel sak å sette opp de riktige parameterne. Dersom klienten som brukes ikke leverer den funksjonen, er den midlertidige løsningen å bruke en lokal Postfix-tjener, og sette den opp til å videresende e-post via den eksterne SMTP-tjeneren. I dette tilfellet vil den lokale Postfixen selv være klienten som autentiserer med SASL. Her er de nødvendige parameterne:

en: The <filename>/etc/postfix/sasl_passwd</filename> file needs to contain the username and password to use for authenticating on the <literal>mail.falcot.com</literal> server. Here is an example:
nb-NO: Filen <filename>/etc/postfix/sasl_passwd</filename> må inneholde brukernavnet og passordet for å autentisere på <literal>mail.falcot.com</literal>-tjeneren. Her er et eksempel:

en: As for all Postfix maps, this file must be turned into <filename>/etc/postfix/sasl_passwd.db</filename> with the <command>postmap</command> command.
nb-NO: Som for alle Postfix-funksjoner, må denne filen bli omgjort til <filename>/etc/postfix/sasl_passwd.db</filename> med <command>postmap</command>-kommandoen.

en: Web Server (HTTP)
nb-NO: Nett-tjener (HTTP)

en: <primary>server</primary><secondary>web</secondary>
nb-NO: <primary>tjener</primary><secondary>web</secondary>

en: <primary>server</primary><secondary>HTTP</secondary>
nb-NO: <primary>tjener</primary><secondary>HTTP</secondary>

en: <primary>HTTP</primary><secondary>server</secondary><seealso>Apache</seealso>
nb-NO: <primary>HTTP</primary><secondary>tjener</secondary><seealso>Apache</seealso>

en: <emphasis>ALTERNATIVE</emphasis> Other web servers
nb-NO: <emphasis>ALTERNATIV</emphasis> Andre nett-tjenere

en: Apache is probably the most widely-known web server, but there are others. Its major opponent is <emphasis role="pkg">nginx</emphasis>, which comes in different packages with different sets of features, like <emphasis role="pkg">nginx-light</emphasis>, <emphasis role="pkg">nginx-full</emphasis>, or <emphasis role="pkg">nginx-extras</emphasis>. Another alternative is <emphasis role="pkg">lighttpd</emphasis>. All of them can offer very good or even better performance under certain workloads or in certain situations, but not all provide the same number of available features and modules.
nb-NO: Apache er antagelig den mest kjente nettleseren, men det finnes mange andre. Hovedutfordreren er <emphasis role="pkg">nginx</emphasis>, som kommer i forskjellige pakker, med forskjellige typer funksjoner, som f.eks. <emphasis role="pkg">nginx-light</emphasis>, <emphasis role="pkg">nginx-full</emphasis>, eller <emphasis role="pkg">nginx-extras</emphasis>. Et annet alternativ er <emphasis role="pkg">lighttpd</emphasis>. Alle tilbyr veldig god eller enda bedre ytelse i noen fall, eller i gitte situasjoner, men ikke alle har samme mengde tilgjengelige funksjoner og moduler.

en: Installing Apache
nb-NO: Å installere Apache

en: Installing the <emphasis role="pkg">apache2</emphasis> package is all that is needed. It contains all the modules, including the <emphasis>Multi-Processing Modules</emphasis> (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate <emphasis role="pkg">apache2-mpm-*</emphasis> packages. It will also pull <emphasis role="pkg">apache2-utils</emphasis> containing the command line utilities that we will discover later.
nb-NO: Å installere <emphasis role="pkg">apache2</emphasis>-pakken er alt som trenges. Den inneholder alle modulene, inkludert <emphasis>Multi-Processing Modules</emphasis> (MPM-er) som påvirker hvordan Apache håndterer parallell behandling av mange forespørsler, som bruker å bli levert i separate <emphasis role="pkg">apache2-mpm-*</emphasis>-pakker. Den vil også trekke på <emphasis role="pkg">apache2-utils</emphasis> som inneholder kommandolinjeverktøy som vi vil oppdage senere.

en: The MPM in use affects significantly the way Apache will handle concurrent requests. With the <emphasis>worker</emphasis> MPM, it uses <emphasis>threads</emphasis> (lightweight processes), whereas with the <emphasis>prefork</emphasis> MPM it uses a pool of processes created in advance. With the <emphasis>event</emphasis> MPM it also uses threads, but the inactive connections (notably those kept open by the HTTP <emphasis>keep-alive</emphasis> feature) are handed back to a dedicated management thread.
nb-NO: Når MPM brukes, påvirkes måten Apache vil håndtere samtidige forespørsler på betydelig. Med <emphasis>worker</emphasis>-MPM, bruker den <emphasis>threads</emphasis> (lettvektprosesser), mens med <emphasis>prefork</emphasis>-MPM bruker den en samling prosesser som er laget på forhånd. Med <emphasis>event</emphasis>-MPM vil den også bruke tråder, men de inaktive tilkoblingene (spesielt de som holdes åpne av HTTP <emphasis>keep-alive</emphasis>-funksjonen) blir levert tilbake til en øremerket management-tråd (ledelsestråd).

en: <emphasis>SECURITY</emphasis> Execution under the <literal>www-data</literal> user
nb-NO: <emphasis>SIKKERHET</emphasis> Kjøring under <literal>www-data</literal>-brukeren

en: <primary>Apache</primary><secondary><literal>www-data</literal>, user</secondary>
nb-NO: <primary>Apache</primary><secondary><literal>www-data</literal>, bruker</secondary>

en: Using the <emphasis>suexec</emphasis> modules, provided by <emphasis role="pkg">apache2-suexec-*</emphasis> packages, allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a <literal>SuexecUserGroup <replaceable>user</replaceable><replaceable>group</replaceable></literal> directive in the Apache configuration.
nb-NO: Ved å bruke <emphasis>suexec</emphasis>-moduler , levert i <emphasis role="pkg">apache2-suexec-*</emphasis> pakkene, kan en omgå denne regelen slik at noen CGI-skript kjøres med identiteten til en annen bruker. Dette settes opp med et <literal>SuexecUserGroup <replaceable>bruker</replaceable><replaceable>gruppe</replaceable></literal>-direktiv i Apache-oppsettet.

en: Another possibility is to use a dedicated MPM, such as the one provided by <emphasis role="pkg">libapache2-mpm-itk</emphasis>. This particular one has a slightly different behavior: it allows “isolating” virtual hosts (actually, sets of pages) so that they each run as a different user. A vulnerability in one website therefore cannot compromise files belonging to the owner of another website.
nb-NO: En annen mulighet er å bruke en dedikert MPM, slik som den som tilbys i <emphasis role="pkg">libapache2-mpm-itk</emphasis>. Akkurat denne har en litt annen oppførsel: Den tillater å «isolere» virtuelle verter (faktisk, sett med sider), slik at hver av dem kjører som en ulik bruker. En sårbarhet i en nettside kan derfor ikke kompromittere filer som tilhører eieren av et annet nettsted.

en: <emphasis>QUICK LOOK</emphasis> List of modules
nb-NO: <emphasis>RASK TITT</emphasis> Liste over moduler

en: Apache is a modular server, and many features are implemented by external modules that the main program loads during its initialization. The default configuration only enables the most common modules, but enabling new modules is a simple matter of running <command>a2enmod <replaceable>module</replaceable></command>; to disable a module, the command is <command>a2dismod <replaceable>module</replaceable></command>. These programs actually only create (or delete) symbolic links in <filename>/etc/apache2/mods-enabled/</filename>, pointing at the actual files (stored in <filename>/etc/apache2/mods-available/</filename>).
nb-NO: Apache er en modulbasert tjener, og mange funksjoner legges inn av eksterne moduler som hovedprogrammet laster inn under sin initialisering. Standardoppsettet kan bare aktivere de mest vanlige moduler, men å tillate nye moduler skjer ved ganske enkelt å kjøre <command>a2enmod <replaceable>modul</replaceable></command>; for å koble fra en modul, er kommandoen <command>a2dismod <replaceable>modul</replaceable></command>. Disse programmene oppretter (eller sletter) bare symbolske lenker i <filename>/etc/apache2/mods-enabled/</filename>, som peker på de aktuelle filene (lagret i <filename>/etc/apache2/mods-available/</filename>).

en: <emphasis>IN PRACTICE</emphasis> Checking the configuration
nb-NO: <emphasis>IN PRACTICE</emphasis> Sjekker oppsettet

en: The <literal>mod_info</literal> module (<command>a2enmod info</command>) allows to access the comprehensive Apache server configuration and information via browser visiting <literal>http://localhost/server-info</literal>. Because it might contain sensitive information, access is only allowed from the local host by default. <ulink type="block" url="https://httpd.apache.org/docs/2.4/mod/mod_info.html" />
nb-NO: <literal>mod_info</literal>-modulen (<command>a2enmod info</command>) gir tilgang til den omfattende Apache-tjeneroppsettet og informasjonen via nettleserbesøk <literal>http://localhost/server-info</literal>. Fordi den kan inneholde sensitiv informasjon, er tilgang bare tillatt fra den lokale verten som standard. <ulink type="block" url="https://httpd.apache.org/docs/2.4/mod/mod_info.html" />

en: With its default configuration, the web server listens on port 80 (as configured in <filename>/etc/apache2/ports.conf</filename>), and serves pages from the <filename>/var/www/html/</filename> directory (as configured in <filename>/etc/apache2/sites-enabled/000-default.conf</filename>).
nb-NO: Med sitt standardoppsett, lytter nettjeneren på port 80 (som satt opp i <filename>/etc/apache2/ports.conf</filename>), og betjener sider fra <filename>/var/www/html/</filename>-mappen (som satt opp i <filename>/etc/apache2/sites-enabled/000-default.conf</filename>).

en: Adding support for SSL
nb-NO: Legge til støtte for SSL

en: Apache 2.4 includes the SSL module (<literal>mod_ssl</literal>) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with <command>a2enmod ssl</command>, then the required directives have to be added to the configuration files. A configuration example is provided in <filename>/etc/apache2/sites-available/default-ssl.conf</filename>. <ulink type="block" url="https://httpd.apache.org/docs/2.4/mod/mod_ssl.html" />
nb-NO: Apache 2.4 inkluderer SSL-modulen (<literal>mod_ssl</literal>) som kreves for sikker HTTP (HTTPS) ut av boksen. Den må bare være aktivert med <command>a2enmod ssl</command>, deretter må de nødvendige direktiver legges til oppsettsfilene. Et oppsettseksempel er gitt i <filename>/etc/apache2/sites-available/default-ssl.conf</filename>. <ulink type="block" url="https://httpd.apache.org/docs/2.4/mod/mod_ssl.html" />

en: If you want to generate trusted certificates, you can follow section <xref linkend="sect.trusted-certs" /> and then adjust the following variables:
nb-NO: Hvis du vil generere klarerte sertifikater, kan du følge seksjon <xref linkend="sect.trusted-certs" /> og deretter justere følgende variabler:

en: 
    SSLCertificateFile      /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/chain.pem
    SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt
nb-NO: 
    SSLCertificateFile      /etc/letsencrypt/live/<replaceable>DOMENE</replaceable>/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/<replaceable>DOMENE</replaceable>/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/<replaceable>DOMENE</replaceable>/chain.pem
    SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt

en: Configuring Virtual Hosts
nb-NO: Oppsett av virtuelle verter

en: A virtual host is an extra identity for the web server.
nb-NO: En virtuell vert er en ekstra identitet for nett-tjeneren.

en: <primary>virtual host</primary>
nb-NO: <primary>virtuell vert</primary>

en: Apache considers two different kinds of virtual hosts: those that are based on the IP address (or the port), and those that rely on the domain name of the web server. The first method requires allocating a different IP address (or port) for each site, whereas the second one can work on a single IP address (and port), and the sites are differentiated by the hostname sent by the HTTP client (which only works in version 1.1 of the HTTP protocol — fortunately that version is old enough that all clients use it already).
nb-NO: Apache vurderer to forskjellige typer virtuelle verter: De som er basert på IP-adressen (eller porten), og de som er avhengige av domenenavnet til nett-tjeneren. Den første metoden krever tildeling av en annen IP-adresse (eller port) for hvert område, mens den andre kan arbeide på en enkelt IP-adresse (og port), og nettstedene er differensiert etter vertsnavnet sendt av HTTP-klienten (som bare fungerer i versjon 1.1 av HTTP-protokollen - heldigvis at versjonen er gammel nok til at alle kunder bruker den allerede).

en: The (increasing) scarcity of IPv4 addresses usually favors the second method; however, it is made more complex if the virtual hosts need to provide HTTPS too, since the SSL protocol hasn't always provided for name-based virtual hosting; the SNI extension (<emphasis>Server Name Indication</emphasis>) that allows such a combination is not handled by all browsers. When several HTTPS sites need to run on the same server, they will usually be differentiated either by running on a different port or on a different IP address (IPv6 can help there).
nb-NO: Den (økende) knapphet på IPv4-adresser favoriserer vanligvis den andre metoden; imidlertid er det gjort mer komplisert om de virtuelle verter må levere HTTPS også, ettersom SSL-protokollen ikke alltid har levert navn-baserte virtuelle verter; Ikke alle nettlesere håndterer SNI-forlengelsen (<emphasis>Server Name Indication</emphasis>). Når flere HTTPS-nettsteder må kjøre på samme tjener, vil de vanligvis bli differensiert enten ved å kjøre på en annen port, eller på en annen IP-adresse (IPv6 kan hjelpe til der).

en: The default configuration for Apache 2 enables name-based virtual hosts. In addition, a default virtual host is defined in the <literal>/etc/apache2/sites-enabled/000-default.conf</literal> file; this virtual host will be used if no host matching the request sent by the client is found.
nb-NO: Standardoppsettet for Apache 2 gir navn-baserte virtuelle verter. I tillegg er en standard virtuell vert definert i <literal>/etc/apache2/sites-enabled/000-default.conf</literal>-filen; Denne virtuelle verten vil bli brukt hvis det ikke finnes en vert som matcher anmodningen fra klienten.

en: <emphasis>CAUTION</emphasis> First virtual host
nb-NO: <emphasis>VÆR VARSOM</emphasis> Første virtuelle vert

en: Requests concerning unknown virtual hosts will always be served by the first defined virtual host, which is why we defined <literal>www.falcot.com</literal> first here.
nb-NO: Forespørsler om ukjente virtuelle verter vil alltid bli betjent med den først definerte virtuelle verten. Det er derfor vi her har definert <literal>www.falcot.com</literal> først.

en: <emphasis>QUICK LOOK</emphasis> Apache supports SNI
nb-NO: <emphasis>RASK TITT</emphasis> Apache støtter SNI

en: The Apache server supports an SSL protocol extension called <emphasis>Server Name Indication</emphasis> (SNI). This extension allows the browser to send the hostname of the web server during the establishment of the SSL connection, much earlier than the HTTP request itself, which was previously used to identify the requested virtual host among those hosted on the same server (with the same IP address and port). This allows Apache to select the most appropriate SSL certificate for the transaction to proceed.
nb-NO: Apache-tjeneren støtter en SSL-protokollforlengelse kalt <emphasis>Server Name Indication</emphasis> (SNI). Denne utvidelsen lar nettleseren sende vertsnavnet til nett-tjeneren, ved etableringen av SSL-tilkoblingen, mye tidligere enn HTTP-forespørselen selv, som tidligere ble brukt til å identifisere den forespurte virtuelle verten blant dem som ligger på samme tjener (med samme IP-adresse og port). Dette gjør Apache ved å velge det mest passende SSL-sertifikatet slik at transaksjonen kan fortsette.

en: Before SNI, Apache would always use the certificate defined in the default virtual host. Clients trying to access another virtual host would then display warnings, since the certificate they received didn't match the website they were trying to access. Fortunately, most browsers now work with SNI; this includes Microsoft Internet Explorer starting with version 7.0 (starting on Vista), Mozilla Firefox starting with version 2.0, Apple Safari since version 3.2.1, and all versions of Google Chrome.
nb-NO: Før SNI, ville Apache alltid bruke sertifikatet i den virtuelle standard verten. Klienter som prøver å få tilgang til en annen virtuell vert vil da vise advarsler, siden sertifikatet de mottok ikke samsvarte med nettstedet de prøvde å få tilgang til. Heldigvis jobber de fleste nettlesere sammen med SNI. Dette inkluderer Microsoft Internet Explorer fra og med versjon 7.0 (som starter med Vista), Mozilla Firefox fra og med versjon 2.0, Apple Safari fra versjon 3.2.1, og alle versjoner av Google Chrome.

en: The Apache package provided in Debian is built with support for SNI; no particular configuration is therefore needed.
nb-NO: Apache-pakken, levert med Debian, er bygget med støtte for SNI. Intet spesielt oppsett er derfor nødvendig.

en: Each extra virtual host is then described by a file stored in <filename>/etc/apache2/sites-available/</filename>. Setting up a website for the <literal>falcot.org</literal> domain is therefore a simple matter of creating the following file, then enabling the virtual host with <command>a2ensite www.falcot.org</command>.
nb-NO: Hver ekstra virtuelle vert er deretter beskrevet av en fil lagret i <filename>/etc/apache2/sites-available/</filename>. Å sette opp et nettsted for <literal>falcot.org</literal>-domenet blir derfor en enkel sak ved å lage den følgende filen, og så aktivere den virtuelle verten med <command>a2ensite www.falcot.org</command>.

en: The <filename>/etc/apache2/sites-available/www.falcot.org.conf</filename> file
nb-NO: <filename>/etc/apache2/sites-available/www.falcot.org.conf</filename>-filen

en: The Apache server, as configured so far, uses the same log files for all virtual hosts (although this could be changed by adding <literal>CustomLog</literal> directives in the definitions of the virtual hosts). It therefore makes good sense to customize the format of this log file to have it include the name of the virtual host. This can be done by creating a <filename>/etc/apache2/conf-available/customlog.conf</filename> file that defines a new format for all log files (with the <literal>LogFormat</literal> directive) and by enabling it with <command>a2enconf customlog</command>. The <literal>CustomLog</literal> line must also be removed (or commented out) from the <filename>/etc/apache2/sites-available/000-default.conf</filename> file.
nb-NO: Apache-tjeneren, satt opp så langt, bruker de samme loggfiler for alle virtuelle verter (selv om dette kan endres ved å legge til <literal>CustomLog</literal>-direktiver i definisjonene til de virtuelle vertene). Det er derfor klokt å tilpasse formatet på denne loggfilen slik at den inneholder navnet på den virtuelle verten. Dette kan gjøres ved å opprette en <filename>/etc/apache2/conf-available/customlog.conf</filename>-fil som fastsetter et nytt format for alle loggfiler (med <literal>LogFormat</literal>-direktivet), og ved å aktivere den med <command>a2enconf customlog</command>. <literal>CustomLog</literal>-linjen må også fjernes (eller kommenteres ut) fra <filename>/etc/apache2/sites-available/000-default.conf</filename>-filen.

en: 
    # New log format including (virtual) host name
    LogFormat "%v %h %l %u %t \"%r\" %&gt;s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost
    
    # Now let's use this "vhost" format by default
    CustomLog /var/log/apache2/access.log vhost
nb-NO: 
    # Nytt loggformat som inneholder (virtuelt) vertsnavn
    LogFormat "%v %h %l %u %t \"%r\" %&gt;s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost
    
    # Så bruker vi dette vhost-formatet som standard
    CustomLog /var/log/apache2/access.log vhost

en: Common Directives
nb-NO: Vanlige direktiver

en: This section briefly reviews some of the commonly-used Apache configuration directives.
nb-NO: Dette avsnittet gir en kort gjennomgang av noen av de oftest brukte Apache-oppsettsdirektivene.

en: <primary>directives, Apache</primary>
nb-NO: <primary>direktiver, Apache</primary>

en: <primary>Apache</primary><secondary>directives</secondary>
nb-NO: <primary>Apache</primary><secondary>direktiver</secondary>

en: The main configuration file usually includes several <literal>Directory</literal> blocks; they allow specifying different behaviors for the server depending on the location of the file being served. Such a block commonly includes <literal>Options</literal> and <literal>AllowOverride</literal> directives.
nb-NO: Den viktigste oppsettsfilen inneholder vanligvis flere <literal>Directory</literal>-blokker. De åpner for å spesifisere ulike virkemåter for tjeneren, avhengig av plasseringen av filen som blir betjent. En slik blokk omfatter vanligvis <literal>Options</literal> og <literal>AllowOverride</literal>-direktiver.

en: Directory block
nb-NO: Katalogblokk

en: The <literal>DirectoryIndex</literal> directive contains a list of files to try when the client request matches a directory. The first existing file in the list is used and sent as a response.
nb-NO: Direktivet <literal>DirectoryIndex</literal> inneholder en liste over filer som kan prøves når klientens forespørsel matcher en katalog. Den første filen som forekommer i listen brukes, og er sendt som en respons.

en: The <literal>Options</literal> directive is followed by a list of options to enable. The <literal>None</literal> value disables all options; correspondingly, <literal>All</literal> enables them all except <literal>MultiViews</literal>. Available options include:
nb-NO: Direktivet <literal>Options</literal> er etterfulgt av en liste av alternativer som kan aktiveres. Verdien <literal>None</literal> slår av alle valg; tilsvarende aktiverer <literal>All</literal> alle sammen unntatt <literal>MultiViews</literal>. Tilgjengelige valg inkluderer:

en: <literal>ExecCGI</literal> indicates that CGI scripts can be executed.
nb-NO: <literal>ExecCGI</literal> indikerer at CGI script kan kjøres.

en: <literal>FollowSymlinks</literal> tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links.
nb-NO: <literal>FollowSymlinks</literal> forteller tjeneren at symbolske lenker kan bli fulgt, og at responsen skal inneholde innholdet av målet for slike koblinger.

en: <literal>Includes</literal> enables <emphasis>Server Side Includes</emphasis> (<emphasis>SSI</emphasis> for short). These are directives embedded in HTML pages and executed on the fly for each request.
nb-NO: <literal>Includes</literal> aktiverer <emphasis>Server Side Includes</emphasis> (<emphasis>SSI</emphasis> i korthet). Dette er direktiver som er innebygd i HTML-sider, og utført underveis for hver forespørsel.

en: <literal>IncludesNOEXEC</literal> allows <emphasis>Server Side Includes</emphasis> (<emphasis>SSI</emphasis>) but disables the <literal>exec</literal> command and limits the <literal>include</literal> directive to text/markup files.
nb-NO: <literal> IncludesNOEXEC</literal> tillater <emphasis>Serverside Includes</emphasis> (<emphasis>SSI</emphasis>), men deaktiverer <literal>exec</literal>-kommandoen og begrenser <literal>include</literal>-direktivet til tekst/tilpassede filer.

en: <literal>Indexes</literal> tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the <literal>DirectoryIndex</literal> directive exists in this directory).
nb-NO: <literal>Indexes</literal> forteller at tjeneren skal vise innholdet i en katalog hvis HTTP-forespørselen sendt av klienten peker på en katalog uten en indeksfil (dvs. når ingen filer nevnt av <literal>DirectoryIndex</literal>-direktivet finnes i denne mappen).

en: <literal>MultiViews</literal> enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser.
nb-NO: <literal>MultiViews</literal> muliggjør forhandlinger om innholdet. Denne kan brukes av tjeneren for å returnere en nettside som matcher det foretrukne språket som er satt opp i nettleseren.

en: <emphasis>BACK TO BASICS</emphasis> <filename>.htaccess</filename> file
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> <filename>.htaccess</filename>-filen

en: The <filename>.htaccess</filename> file contains Apache configuration directives enforced each time a request concerns an element of the directory where it is stored. The scope of these directives also recurses to all the subdirectories within.
nb-NO: Filen <filename>.htaccess</filename> inneholder oppsettsdirektiver for Apache som utføres hver gang en forespørsel om et element i katalogen der den er lagret. Definisjonsområdet for disse direktivene gjentas også for alle underkatalogene.

en: Most of the directives that can occur in a <literal>Directory</literal> block are also legal in a <filename>.htaccess</filename> file.
nb-NO: De fleste direktiver som kan forekomme i en <literal>Directory</literal>-blokk gjelder også for en <filename>.htaccess</filename>-fil.

en: The <literal>AllowOverride</literal> directive lists all the options that can be enabled or disabled by way of a <filename>.htaccess</filename> file. A common use of this option is to restrict <literal>ExecCGI</literal>, so that the administrator chooses which users are allowed to run programs under the web server's identity (the <literal>www-data</literal> user).
nb-NO: Direktivet <literal>AllowOverride</literal> lister opp alle alternativer som kan aktiveres eller deaktiveres ved hjelp av en <filename>.htaccess</filename>-fil. En vanlig bruk av dette valget er til å begrense <literal>ExecCGI</literal>, slik at administratoren velger hvilke brukere som har lov til å kjøre programmer under nett-tjenerens identitet (<literal>www-data</literal>-brukeren).

en: Requiring Authentication
nb-NO: Å kreve autentisering

en: <primary>web authentication</primary>
nb-NO: <primary>web-autentiseringn</primary>

en: <primary>Apache</primary><secondary>password-based authentication</secondary>
nb-NO: <primary>Apache</primary><secondary>passordbasert tilgangskontroll</secondary>

en: <filename>.htaccess</filename> file requiring authentication
nb-NO: <filename>.htaccess</filename>-fil som krever autentisering

en: 
    Require valid-user
    AuthName "Private directory"
    AuthType Basic
    AuthUserFile /etc/apache2/authfiles/htpasswd-private
nb-NO: 
    Require valid-user
    AuthName "Privat katalog"
    AuthType Basic
    AuthUserFile /etc/apache2/authfiles/htpasswd-private

en: <emphasis>SECURITY</emphasis> No security
nb-NO: <emphasis>SIKKERHET</emphasis> Ingen sikkerhet

en: The authentication system used in the above example (<literal>Basic</literal>) has minimal security as the password is sent in clear text (it is only encoded as <emphasis>base64</emphasis>, which is a simple encoding rather than an encryption method). It should also be noted that the documents “protected” by this mechanism also go over the network in the clear. If security is important, the whole HTTP connection should be encrypted with SSL.
nb-NO: Autentiseringssystemet som brukes i eksemplet ovenfor (<literal>Basic</literal>) har minimal sikkerhet når passordet sendes i klartekst (det er bare kodet som <emphasis>base64</emphasis>, som er en enkel innkoding snarere enn en krypteringsmetode). Det bør også bemerkes at de dokumenter som er «beskyttet» av denne mekanismen også går over nettverket i klartekst. Hvis sikkerhet er viktig, bør hele HTTP-tilkobling krypteres med SSL.

en: The <filename>/etc/apache2/authfiles/htpasswd-private</filename> file contains a list of users and passwords; it is commonly manipulated with the <command>htpasswd</command> command. For example, the following command is used to add a user or change their password:
nb-NO: Filen <filename>/etc/apache2/authfiles/htpasswd-private</filename> inneholder en liste over brukere og passord. Den er ofte håndtert med <command>htpasswd</command>-kommandoen. For eksempel brukes følgende kommando til å legge til en bruker eller endre passordet deres:

en: Restricting Access
nb-NO: Adgangsbegrensning

en: <primary>web access restriction</primary>
nb-NO: <primary>nettilgang begrensning</primary>

en: <primary>Apache</primary><secondary>IP-based authentication</secondary>
nb-NO: <primary>Apache</primary><secondary>IP-basert tilgangsstyring</secondary>

en: The <literal>Require</literal> directive controls access restrictions for a directory (and its subdirectories, recursively). <ulink type="block" url="https://httpd.apache.org/docs/2.4/howto/access.html" />
nb-NO: Direktivet <literal>Require</literal> regulerer adgangsbegrensninger for en katalog (og gjentatt for katalogens undermapper). <ulink type="block" url="https://httpd.apache.org/docs/2.4/howto/access.html" />

en: It can be used to restrict access based on many criteria; we will stop at describing access restriction based on the IP address of the client, but it can be made much more powerful than that, especially when several <literal>Require</literal> directives are combined within a <literal>RequireAll</literal> block.
nb-NO: Den kan brukes til å begrense adgangen basert på flere kriterier: Vi vil stoppe med å beskrive adgangsbegrensning basert på klientens IP-adresse, men det kan gjøres mye kraftigere enn det, særlig når flere <literal>Require</literal>-direktiver kombineres i en <literal>RequireAll</literal>-blokk.

en: Only allow from the local network
nb-NO: Tillat bare fra det lokale nettverket

en: <emphasis>ALTERNATIVE</emphasis> Old syntax
nb-NO: <emphasis>ALTERNATIV</emphasis> Gammel syntaks

en: The <literal>Require</literal> syntax is only available in Apache 2.4 (the version shipped since <emphasis role="distribution">Jessie</emphasis>). For users of <emphasis role="distribution">Wheezy</emphasis>, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the <literal>mod_access_compat</literal> module.
nb-NO: <literal>Require</literal>-syntaksen er bare tilgjengelig i Apache 2.4 (versjonen levert etter <emphasis role="distribution">Jessie</emphasis>). For brukere av <emphasis role="distribution">Wheezy</emphasis> er Apache 2,2-syntaksen forskjellig, og her beskriver vi den hovedsakelig som referanse, selv om den også kan gjøres tilgjengelig i Apache 2,4 ved hjelp av <literal>mod_access_compat</literal>-modulen.

en: The <literal>Allow from</literal> and <literal>Deny from</literal> directives control access restrictions for a directory (and its subdirectories, recursively).
nb-NO: Direktivene <literal>Allow from</literal> og <literal>Deny from</literal> kontrollerer adgangsbegrensninger for en katalog (og gjentatt for katalogens undermapper).

en: The <literal>Order</literal> directive tells the server of the order in which the <literal>Allow from</literal> and <literal>Deny from</literal> directives are applied; the last one that matches takes precedence. In concrete terms, <literal>Order deny,allow</literal> allows access if no <literal>Deny from</literal> applies, or if an <literal>Allow from</literal> directive does. Conversely, <literal>Order allow,deny</literal> rejects access if no <literal>Allow from</literal> directive matches (or if a <literal>Deny from</literal> directive applies).
nb-NO: <literal>Order</literal>-direktivet forteller tjeneren om rekkefølgen på <literal>Allow from</literal> og <literal>Deny from</literal>-direktivene; den siste som matcher har forrang. Konkret tillater <literal>Order deny,allow</literal> adgang hvis ingen <literal>Deny from</literal> passer, eller hvis et <literal>Allow from</literal>-direktiv gjør det. Omvendt, stanser <literal>Order allow,deny</literal> adgang hvis intet <literal>Allow from</literal>-direktiv matcher (eller hvis et <literal>Deny from</literal>-direktiv tillater).

en: The <literal>Allow from</literal> and <literal>Deny from</literal> directives can be followed by an IP address, a network (such as <literal>192.168.0.0/255.255.255.0</literal>, <literal>192.168.0.0/24</literal> or even <literal>192.168.0</literal>), a hostname or a domain name, or the <literal>all</literal> keyword, designating everyone.
nb-NO: Direktivene <literal>Allow from</literal> og <literal>Deny from</literal> kan etterfølges av en IP-adresse, et nettverk (slik som <literal>192.168.0.0/255.255.255.0</literal>, <literal>192.168.0.0/24</literal>, eller til og med <literal>192.168.0</literal>), et vertsnavn eller domenenavn, eller <literal>all</literal>-nøkkelen som peker ut alle.

en: For instance, to reject connections by default but allow them from the local network, you could use this:
nb-NO: For eksempel, for å avvise forbindelser som standard, men tillate dem fra det lokale nettverket, kan du bruke denne:

en: Log Analyzers
nb-NO: Logg-analysatorer

en: A log analyzer is frequently installed on a web server; since the former provides the administrators with a precise idea of the usage patterns of the latter.
nb-NO: En logg-analysator er ofte installert på en nett-tjener; siden den første gir administratorer en presis idé om bruksmønstre på sistnevnte.

en: The Falcot Corp administrators selected <emphasis>AWStats</emphasis> (<emphasis>Advanced Web Statistics</emphasis>) to analyze their Apache log files.
nb-NO: Falcot Corp-administratorene valgte <emphasis>AWStats</emphasis> (<emphasis>Advanced Web Statistics</emphasis>) til å analysere sine Apache-loggfiler.

en: <primary>web logs analyzer</primary>
nb-NO: <primary>analysator av web-logger</primary>

en: <primary>Apache</primary><secondary>log analyzer</secondary>
nb-NO: <primary>Apache</primary><secondary>logganalysator</secondary>

en: The first configuration step is the customization of the <filename>/etc/awstats/awstats.conf</filename> file. The Falcot administrators keep it unchanged apart from the following parameters:
nb-NO: Det første oppsettstrinnet er å tilpasse <filename>/etc/awstats/awstats.conf</filename>-filen. Falcot-administratorene holdt den uendret, bortsett fra følgende parametre:

en: All these parameters are documented by comments in the template file. In particular, the <varname>LogFile</varname> and <varname>LogFormat</varname> parameters describe the location and format of the log file and the information it contains; <varname>SiteDomain</varname> and <varname>HostAliases</varname> list the various names under which the main web site is known.
nb-NO: Alle disse parametrene er dokumentert av kommentarer i male-filen. Spesielt beskriver <varname>LogFile</varname> og <varname>LogFormat</varname>-parameterene, plasseringen og formatet på loggfilen og informasjonen den inneholder;<varname>SiteDomain</varname> og <varname>HostAliases</varname> lister de ulike navnene som hovednettstedet er kjent under.

en: For high traffic sites, <varname>DNSLookup</varname> should usually not be set to <literal>1</literal>; for smaller sites, such as the Falcot one described above, this setting allows getting more readable reports that include full machine names instead of raw IP addresses.
nb-NO: For områder med stor trafikk skal <varname>DNSLookup</varname> vanligvis ikke settes til <literal>1</literal>. For mindre nettsteder, som for eksempel Falcot-eksemplet beskrevet ovenfor, tillater denne innstillingen mer lesbare rapporter med komplette maskinnavn i stedet for rå (enkle) IP-adresser.

en: <emphasis>SECURITY</emphasis> Access to statistics
nb-NO: <emphasis>SIKKERHET</emphasis> Tilgang til statistikk

en: AWStats makes its statistics available on the website with no restrictions by default, but restrictions can be set up so that only a few (probably internal) IP addresses can access them; the list of allowed IP addresses needs to be defined in the <varname>AllowAccessFromWebToFollowingIPAddresses</varname> parameter
nb-NO: AWStats gjør statistikk tilgjengelig på nettstedet uten restriksjoner som standard. Men restriksjoner kan settes opp slik at bare noen få (sannsynligvis interne) IP-adresser kan få tilgang til dem. Listen over tillatte IP-adresser må være definert i <varname>AllowAccessFromWebToFollowingIPAddresses</varname>-parameteret

en: AWStats will also be enabled for other virtual hosts; each virtual host needs its own configuration file, such as <filename>/etc/awstats/awstats.www.falcot.org.conf</filename>.
nb-NO: AWStats er også aktivert for andre virtuelle verter; hver virtuell vert må ha en egen oppsettsfil, som for eksempel <filename>/etc/awstats/awstats.www.falcot.org.conf</filename>.

en: AWStats configuration file for a virtual host
nb-NO: AWStats oppsettsfil for en virtuell vert

en: After a few minutes (and once the script has been run a few times), the results are available online: <ulink type="block" url="http://www.falcot.com/cgi-bin/awstats.pl" /><ulink type="block" url="http://www.falcot.org/cgi-bin/awstats.pl" />
nb-NO: Etter noen minutter (og så snart skriptet er kjørt et par ganger), er resultatene tilgjengelig på nettet: <ulink type="block" url="http://www.falcot.com/cgi-bin/awstats.pl" /><ulink type="block" url="http://www.falcot.org/cgi-bin/awstats.pl" />

en: <emphasis>CAUTION</emphasis> Log file rotation
nb-NO: <emphasis>VÆR VARSOM</emphasis> Loggfil-rotasjon

en: FTP File Server
nb-NO: FTP-filtjener

en: <primary>server</primary><secondary>file</secondary>
nb-NO: <primary>tjener</primary><secondary>fil</secondary>

en: <primary>server</primary><secondary>FTP</secondary>
nb-NO: <primary>tjener</primary><secondary>FTP</secondary>

en: FTP (<emphasis>File Transfer Protocol</emphasis>) is one of the first protocols of the Internet (RFC 959 was issued in 1985!). It was used to distribute files before the Web was even born (the HTTP protocol was created in 1990, and formally defined in its 1.0 version by RFC 1945, issued in 1996).
nb-NO: FTP (<emphasis>File Transfer Protocol</emphasis>) (Filoverføringsprotokoll) er en av de første protokollene for Internett (RFC 959 ble utstedt i 1985!). Den ble brukt til å distribuere filer før nettet til og med var født (HTTP-protokollen ble laget i 1990, og formelt definert i sin 1.0-versjon av RFC 1945, utgitt i 1996).

en: FTP is not a secure protocol. User names, passwords, and data are transported in clear text. To increase the security, one can use FTP via implicit (enforced) or explicit (requested) SSL/TLS, also known as FTPS, but not to be confused with <emphasis>SFTP</emphasis>, the SSH File Transfer Protocol, an alternative file transfer implementation using SSH. Many FTP server packages in Debian support FTPS.
nb-NO: FTP er ikke en sikret protokoll. Brukernavn, passord, og data transporteres i klartekst. For å øke sikkerheten kan man bruke FTP med implisitt (påtvunget) eller eksplisitt (forespurt) SSL/TLS, også kjent som FTPS, til forveksling likt <emphasis>SFTP</emphasis>, SSH-filoverføringsprotokollen, en alternativ implementasjon som bruker SSH. Mange FTP-tjenerpakker i Debian støtter FTPS.

en: Other FTP servers are mainly used to distribute files for public downloading; Debian packages are a good example. The contents of these servers is fetched from other, geographically remote, servers; it is then made available to less distant users. This means that client authentication is not required; as a consequence, this operating mode is known as “anonymous FTP”. To be perfectly correct, the clients do authenticate with the <literal>anonymous</literal> username; the password is often, by convention, the user's email address, but the server ignores it.
nb-NO: Andre FTP-tjenere brukes i hovedsak til å distribuere filer for offentlig nedlasting: Debian-pakker er et godt eksempel. Innholdet i disse tjenerne er hentet fra andre, geografisk fjerntliggende tjenere, og gjøres da tilgjengelige for mindre fjerntliggende brukere. Dette betyr at klientautentisering ikke er nødvendig. Som et resultat er denne driftsmodus kjent som «anonymus FTP». For å være helt korrekt autentiseres klientene med brukernavnet <literal>anonymous</literal>; passordet er ofte, ifølge vanlig praksis, brukerens e-postadresse, men det ignorerer tjeneren.

en: Installing the package creates an <literal>ftp</literal> system user. This account is always used for anonymous FTP connections, and its home directory (<filename>/srv/ftp/</filename>) is the root of the tree made available to users connecting to this service. The default configuration (in <filename>/etc/vsftpd.conf</filename>) requires some changes to cater to the simple need of making big files available for public downloads: anonymous access needs to be enabled (<literal>anonymous_enable=YES</literal>) and read-only access of local users needs to be disabled (<literal>local_enable=NO</literal>). The latter is particularly important since the FTP protocol doesn't use any form of encryption and the user password could be intercepted over the wire.
nb-NO: Å installere pakken skaper en <literal>ftp</literal> systembruker. Denne kontoen brukes alltid for anonyme FTP-tilkoblinger, og hjemmekatalogen dens (<filename>/srv/ftp/</filename>) er roten til treet som brukerne kan benytte for å knytte seg til denne tjenesten. Standardoppsettet (i <filename>/etc/vsftpd.conf</filename>) krever noen endringer for å imøtekomme enkle behov for å gjøre store filer tilgjengelig for offentlige nedlastinger: Anonym tilgang må være aktivert (<literal>anonymous_enable=YES</literal>), og lesetilgang fra lokale brukere må være deaktivert (<literal>local_enable=NO</literal>). Det siste er spesielt viktig ettersom FTP-protokollen ikke bruker noen form for kryptering, og brukerpassord kan bli snappet opp underveis.

en: NFS File Server
nb-NO: NFS-filtjener

en: <primary>server</primary><secondary>NFS</secondary>
nb-NO: <primary>tjener</primary><secondary>NFS</secondary>

en: NFS (<emphasis>Network File System</emphasis>) is a protocol allowing remote access to a filesystem through the network. All Unix systems can work with this protocol.
nb-NO: NFS (<emphasis>Network File System</emphasis>) er en protokoll som tillater ekstern tilgang til et filsystem gjennom nettverket. Alle Unix-systemer kan arbeide med denne protokollen.

en: <emphasis>SPECIFIC CASE</emphasis> Microsoft Windows and NFS Shares
nb-NO: <emphasis>KONKRET SAK</emphasis> Microsoft Windows og NFS-områder

en: When older or (so called) "Home" variants of Windows are involved, usually Samba (<xref linkend="sect.windows-file-server-with-samba" />) must be used instead of NFS. Modern Windows Server and "Pro" or "Enterprise" Desktop solutions however have built-in support for NFS. After installation of the "Services for NFS" components NFS shares can be accessed and temporarily or permanently mounted like any other network share. Be aware of possible encoding issues in file names.
nb-NO: Når eldre eller (såkalte) "Home"-varianter av Windows er involvert, må vanligvis Samba (<xref linkend="sect.windows-file-server-with-samba" />) brukes i stedet for NFS. Moderne Windows Server og "Pro" eller "Enterprise" Desktop-løsninger har imidlertid innebygd støtte for NFS. Etter installasjon av komponenten "NFS-tjenester" kan NFS områder nås og permanent eller midlertidig monteres som alle andre nettverksressurser. Vær oppmerksom på mulige kodingsproblemer i filnavn.

en: <primary>Network File System</primary><secondary>Windows client</secondary>
nb-NO: <primary>Nettverksfilsystem</primary><secondary>Windows klient</secondary>

en: <primary>filesystem</primary><secondary>network</secondary>
nb-NO: <primary>filsystem</primary><secondary>nettverk</secondary>

en: <primary>file</primary><secondary>server</secondary>
nb-NO: <primary>fil</primary><secondary>tjener</secondary>

en: NFS is a very useful tool but, historically, it has suffered from many limitations, most of which have been addressed with version 4 of the protocol. The downside is that the latest version of NFS is harder to configure when you want to make use of basic security features such as authentication and encryption since it relies on Kerberos for those parts. And without those, the NFS protocol must be restricted to a trusted local network since data goes over the network unencrypted (a <emphasis>sniffer</emphasis> can intercept it) and access rights are granted based on the client's IP address (which can be spoofed).
nb-NO: NFS er et svært nyttig verktøy, men har tidligere lidd av mange begrensninger, som det er tatt hensyn til i versjon 4 av protokollen. Ulempen er at den nyeste versjonen av NFS er vanskeligere å sette opp når du ønsker å bruke grunnleggende sikkerhetsfunksjoner som autentisering og kryptering, da den trenger Kerberos for dette. Og uten disse må NFS-protokollen begrenses til et klarert lokalt nettverk når data ukryptert går over nettverket (en <emphasis>sniffer</emphasis> kan fange den opp), og adgangsrettighetene er gitt med utgangspunkt i klientens IP-adresse (som kan etterlignes).

en: <emphasis>DOCUMENTATION</emphasis> NFS HOWTO
nb-NO: <emphasis>DOKUMENTASJON</emphasis> NFS HOWTO

en: Good documentation to deploy NFSv4 is rather scarce. Here are some pointers with content of varying quality but that should at least give some hints on what should be done. <ulink type="block" url="https://help.ubuntu.com/community/NFSv4Howto" /> <ulink type="block" url="https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration" />
nb-NO: Det er ganske knapt med god dokumentasjon om å rulle ut NFSv4. Her er noen tips med innhold av varierende kvalitet, men det bør i det minste gi noen hint om hva som bør gjøres. <ulink type="block" url="https://help.ubuntu.com/community/NFSv4Howto" /> <ulink type="block" url="https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration" />

en: Securing NFS
nb-NO: Sikring av NFS

en: <primary>NFS</primary><secondary>security</secondary>
nb-NO: <primary>NFS</primary><secondary>sikkerhet</secondary>

en: If you don't use the Kerberos-based security features, it is vital to ensure that only the machines allowed to use NFS can connect to the various required RPC servers, because the basic protocol trusts the data received from the network. The firewall must also block <emphasis>IP spoofing</emphasis> so as to prevent an outside machine from acting as an inside one, and access to the appropriate ports must be restricted to the machines meant to access the NFS shares.
nb-NO: Hvis du ikke bruker Kerberos-baserte sikkerhetsfunksjoner, er det viktig å sikre at bare de maskinene som har lov til å bruke NFS kan koble til de ulike nødvendige RPC-tjenerne, fordi den grunnleggende protokollen har tillit til data som mottas fra nettverket. Brannmuren må også blokkere <emphasis>IP spoofing</emphasis> for å hindre at en utenforstående maskin opptrer som en på innsiden, og at tilgangen til de riktige portene blir begrenset til maskinene som er ment å skulle ha tilgang til NFS-delinger.

en: <emphasis>BACK TO BASICS</emphasis> RPC
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> RPC

en: RPC (<emphasis>Remote Procedure Call</emphasis>) is a Unix standard for remote services. NFS is one such service.
nb-NO: RPC (<emphasis>Remote Procedure Call</emphasis>) er en Unix-standard for eksterne tjenester. NFS er en slik tjeneste.

en: RPC services register to a directory known as the <emphasis>portmapper</emphasis>. A client wishing to perform an NFS query first addresses the <emphasis>portmapper</emphasis> (on port 111, either TCP or UDP), and asks for the NFS server; the reply usually mentions port 2049 (the default for NFS). Not all RPC services necessarily use a fixed port.
nb-NO: RPC-tjenester registrerer til en katalog kjent som <emphasis>portmapper</emphasis>. En klient som ønsker NFS-forespørsel, adresserer først til <emphasis>portmapper</emphasis> (på port 111, enten TCP eller UDP), og ber om NFS-tjeneren; svaret nevner vanligvis port 2049 (standard for NFS). Ikke alle RPC-tjenester bruker nødvendigvis en fast port.

en: Older versions of the protocol required other RPC services which used dynamically assigned ports. Fortunately, with NFS version 4, only port 2049 (for NFS) and 111 (for the portmapper) are needed and they are thus easy to firewall.
nb-NO: Eldre versjoner av protokollen krevde andre RPC-tjenester som brukte dynamisk tildelte porter. Heldigvis, med NFS versjon 4, er bare port 2049 (for NFS) og 111 (for portmapper) nødvendig, og de er dermed lette å sikre med brannmur.

en: NFS Server
nb-NO: NFS-tjener

en: <primary>NFS</primary><secondary>server</secondary>
nb-NO: <primary>NFS</primary><secondary>tjener</secondary>

en: The NFS server is part of the Linux kernel; in kernels provided by Debian it is built as a kernel module. If the NFS server is to be run automatically on boot, the <emphasis role="pkg">nfs-kernel-server</emphasis> package should be installed; it contains the relevant start-up scripts.
nb-NO: NFS er en del av Linux-kjernen; i kjerner som leveres av Debian er den med som en kjernemodul. Hvis NFS-tjeneren skal kjøres automatisk ved oppstart, skal <emphasis role="pkg">nfs-kernel-server</emphasis>-pakken installeres; Den inneholder de relevante oppstartsskriptene.

en: 
    /directory/to/share machine1(option1,option2,...) machine2(...) ...
nb-NO: 
    /katalog/som/deles maskin1(opsjon1,opsjon2,...) maskin2(...) ...

en: Note that with NFSv4, all exported directories must be part of a single hierarchy and that the root directory of that hierarchy must be exported and identified with the option <literal>fsid=0</literal> or <literal>fsid=root</literal>.
nb-NO: Merk at med NFSv4 må alle eksporterte kataloger være del av et enkelt hierarki, og at rotkatalogen i dette hierarkiet må eksporteres og identifiseres med alternativet <literal>fsid=0</literal>, eller <literal>fsid=root</literal>.

en: Each machine can be identified either by its DNS name or its IP address. Whole sets of machines can also be specified using either a syntax such as <literal>*.falcot.com</literal> or an IP address range such as <literal>192.168.0.0/255.255.255.0</literal> or <literal>192.168.0.0/24</literal>.
nb-NO: Hver maskin kan identifiseres enten ved sitt DNS-navn eller sin IP-adresse. Hele sett med maskiner kan også angis ved hjelp av enten en syntaks som <literal>*.falcot.com</literal>, eller et IP-adresseområde som <literal>192.168.0.0/255.255.255.0</literal>, eller <literal>192.168.0.0/24</literal>.

en: Directories are made available as read-only by default (or with the <literal>ro</literal> option). The <literal>rw</literal> option allows read-write access. NFS clients typically connect from a port restricted to root (in other words, below 1024); this restriction can be lifted by the <literal>insecure</literal> option (the <literal>secure</literal> option is implicit, but it can be made explicit if needed for clarity).
nb-NO: Kataloger er som standard gjort tilgjengelig som skrivebeskyttet (eller med <literal>ro</literal>-valget). Valget <literal>rw</literal> tillater lese- og skriveadgang. NFS-klienten kobler vanligvis til fra en port forbeholdt rot (med andre ord, under 1024). Denne begrensningen kan oppheves av <literal>insecure</literal>-valget, (<literal>secure</literal>-alternativet er implisitt, men kan gjøres eksplisitt hvis det er nødvendig for klarhetens skyld).

en: <primary>NFS</primary><secondary>options</secondary>
nb-NO: <primary>NFS</primary><secondary>opsjoner</secondary>

en: By default, the server only answers an NFS query when the current disk operation is complete (<literal>sync</literal> option); this can be disabled with the <literal>async</literal> option. Asynchronous writes increase performance a bit, but they decrease reliability since there is a data loss risk in case of the server crashing between the acknowledgment of the write and the actual write on disk. Since the default value changed recently (as compared to the historical value of NFS), an explicit setting is recommended.
nb-NO: Som standard svarer tjeneren bare på en NFS-spørring når den igangværende diskoperasjonen er fullført (<literal>sync</literal>-valget); dette kan oppheves med <literal>async</literal>-valget. Asynkron innskriving øker ytelsen litt, men de reduserer påliteligheten siden det er en risiko for tap av data i tilfelle tjeneren krasjer mellom godkjenningen av innskrivingen, og den faktiske innskrivingen på disken. Siden standardverdien nettopp ble endret (i forhold til den historiske verdien av NFS), er en eksplisitt innstilling å anbefale.

en: In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the <literal>nobody</literal> user. This behavior corresponds to the <literal>root_squash</literal> option, and is enabled by default. The <literal>no_root_squash</literal> option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user <literal>nobody</literal>, use <literal>all_squash</literal>. The <literal>anonuid=<replaceable>uid</replaceable></literal> and <literal>anongid=<replaceable>gid</replaceable></literal> options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user <literal>nobody</literal> and group <literal>nogroup</literal>).
nb-NO: For å ikke gi rot-tilgang til filsystemet til noen NFS-klient, blir alle forespørsler som ser ut til å komme fra en rotbruker ansett av tjeneren å komme fra <literal>nobody</literal>-brukeren. Dette samsvarer med <literal>root_squash</literal>-alternativet, og er aktivert som standard. Alternativet <literal>no_root_squash</literal>, som slår av denne oppførselen, er risikabel, og bør bare brukes i kontrollerte omgivelser. Hvis alle brukere skal kobles til brukeren <literal>nobody</literal>, bruk <literal>all_squash</literal>. <literal>anonuid=<replaceable>uid</replaceable></literal> og <literal>anongid=<replaceable>gid</replaceable></literal>-alternativene tillater å spesifisere en annen falsk bruker til å bli brukt i stedet for UID/GID 65534 (som tilsvarer bruker <literal>nobody</literal> og gruppe <literal>nogroup</literal>).

en: With NFSv4, you can add a <literal>sec</literal> option to indicate the security level that you want: <literal>sec=sys</literal> is the default with no special security features, <literal>sec=krb5</literal> enables authentication only, <literal>sec=krb5i</literal> adds integrity protection, and <literal>sec=krb5p</literal> is the most complete level which includes privacy protection (with data encryption). For this to work you need a working Kerberos setup (that service is not covered by this book).
nb-NO: Med NFSv4 kan du legge til et <literal>sec</literal>-valg for å indikere det sikkerhetsnivået du ønsker: <literal>sec=sys</literal> er som standard uten noen sikkerhetsegenskaper, <literal>sec=krb5</literal> aktiverer bare autentisering, <literal>sec=krb5i</literal> legger til integritetsbeskyttelse, og <literal>sec=krb5p</literal> er det mest komplette nivået, og inkluderer personvern (med datakryptering). For at dette skal virke, trenger du et Kerberos oppsett som virker (den tjenesten er ikke dekket i denne boken).

en: Other options are available; they are documented in the <citerefentry><refentrytitle>exports</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page.
nb-NO: Det er også andre valgmuligheter. De er dokumentert i manualsiden <citerefentry><refentrytitle>exports</refentrytitle> <manvolnum>5</manvolnum></citerefentry>.

en: <emphasis>CAUTION</emphasis> First installation
nb-NO: <emphasis>VÆR VARSOM</emphasis> Første innstallasjon

en: NFS Client
nb-NO: NFS-klient

en: <primary>client</primary><secondary>NFS</secondary>
nb-NO: <primary>klient</primary><secondary>NFS</secondary>

en: <primary>NFS</primary><secondary>client</secondary>
nb-NO: <primary>NFS</primary><secondary>klient</secondary>

en: Manually mounting with the <command>mount</command> command
nb-NO: Å montere manuelt med <command>mount</command>-kommandoen

en: NFS entry in the <filename>/etc/fstab</filename> file
nb-NO: NFS-inngang i <filename>/etc/fstab</filename>-filen

en: The entry described above mounts, at system startup, the NFS directory <filename>/shared/</filename> from the <literal>arrakis</literal> server into the local <filename>/srv/shared/</filename> directory. Read-write access is requested (hence the <literal>rw</literal> parameter). The <literal>nosuid</literal> option is a protection measure that wipes any <literal>setuid</literal> or <literal>setgid</literal> bit from programs stored on the share. If the NFS share is only meant to store documents, another recommended option is <literal>noexec</literal>, which prevents executing programs stored on the share. Note that on the server, the <filename>shared</filename> directory is below the NFSv4 root export (for example <filename>/export/shared</filename>), it is not a top-level directory.
nb-NO: Inngangen beskrevet ovenfor, monterer ved systemoppstart, NFS-mappen <filename>/shared/</filename> fra <literal>arrakis</literal>-tjeneren til den lokale <filename>/srv/shared/</filename>-mappen. Lese- og skriveadgang kreves (derav <literal>rw</literal>-parameteret). Valget <literal>nosuid</literal> er et beskyttelsestiltak som sletter alle <literal>setuid</literal>, eller <literal>setgid</literal>-bit fra programmer lagret i delingen. Hvis NFS-delingen kun er ment til å lagre dokumenter, er et annet anbefalt alternativ <literal>noexec</literal>, som hindrer kjøring av programmer som er lagret i delingen. Legg merke til at på tjeneren er ikke <filename>shared</filename>-mappen under NFSv4 root export (for eksempel <filename>/export/shared</filename>), en toppnivåmappe.

en: The <citerefentry><refentrytitle>nfs</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the options in some detail.
nb-NO: Manualsiden <citerefentry><refentrytitle>nfs</refentrytitle> <manvolnum>5</manvolnum></citerefentry> beskriver alle valgmulighetene noe mer detaljert.

en: Setting Up Windows Shares with Samba
nb-NO: Oppsett av Windows Shares med Samba

en: <primary>Windows share</primary>
nb-NO: <primary>Delt Windows-område</primary>

en: <primary>server</primary><secondary>SMB</secondary>
nb-NO: <primary>tjener</primary><secondary>SMB</secondary>

en: <primary>server</primary><secondary>CIFS</secondary>
nb-NO: <primary>tjener</primary><secondary>CIFS</secondary>

en: Samba is a suite of tools handling the SMB protocol (also known as “CIFS”) on Linux. This protocol is used by Windows for network shares and shared printers.
nb-NO: Samba er en pakke med verktøy som håndterer SMB-protokollen (også kjent som «CIFS») på Linux. Denne protokollen brukes av Windows for nettverksressurser og delte skrivere.

en: Samba can also act as a Windows domain controller. This is an outstanding tool for ensuring seamless integration of Linux servers and the office desktop machines still running Windows.
nb-NO: Samba kan også virke som en Windows domenekontrollør. Denne er et enestående verktøy for å sikre sømløs integrasjon av Linux-tjenere og stasjonære kontormaskiner som fortsatt kjører Windows.

en: Samba Server
nb-NO: Samba-tjener

en: <primary>server</primary><secondary>Samba</secondary>
nb-NO: <primary>tjener</primary><secondary>Samba</secondary>

en: <primary>Samba</primary><secondary>installation</secondary>
nb-NO: <primary>Samba</primary><secondary>installasjon</secondary>

en: <primary>Samba</primary><secondary>server</secondary>
nb-NO: <primary>Samba</primary><secondary>tjener</secondary>

en: The <emphasis role="pkg">samba</emphasis> package contains the main two servers of Samba 4, <command>smbd</command> and <command>nmbd</command>.
nb-NO: Pakken <emphasis role="pkg">samba</emphasis> inneholder Samba 4s to hovedtjenere, <command>smbd</command> og <command>nmbd</command>.

en: <emphasis>DOCUMENTATION</emphasis> Going further
nb-NO: <emphasis>DOKUMENTASJON</emphasis> For viderekommende

en: <primary>domain controller</primary>
nb-NO: <primary>domenekontroller</primary>

en: <primary>Windows domain</primary>
nb-NO: <primary>Windows-domene</primary>

en: <primary>Samba</primary><secondary>domain controller</secondary>
nb-NO: <primary>Samba</primary><secondary>domenekontroller</secondary>

en: The <emphasis role="pkg">samba</emphasis> package contains all the necessary manual pages and in <filename>/usr/share/doc/samba/examples/</filename> a wealth of commented example files. If you are looking for a more comprehensive documentation, you may check the <emphasis>Samba</emphasis> website. <ulink type="block" url="https://www.samba.org/samba/docs/" />
nb-NO: <emphasis role="pkg">samba</emphasis>-pakken inneholder alle nødvendige manualsider og i <filename>/usr/share/doc/samba/examples/</filename> et vell av kommenterte eksempelfiler. Hvis du er ute etter en mer omfattende dokumentasjon, kan du sjekke nettstedet <emphasis>Samba</emphasis>. <ulink type="block" url="https://www.samba.org/samba/docs/" />

en: <emphasis>TOOL</emphasis> Authenticating with a Windows Server
nb-NO: <emphasis>VERKTØY</emphasis> Autentisering med en Windows-tjener

en: Winbind gives system administrators the option of using a Windows server as an authentication server. Winbind also integrates cleanly with PAM and NSS. This allows setting up Linux machines where all users of a Windows domain automatically get an account.
nb-NO: Winbind gir systemadministratorer muligheten til å bruke en Windows-tjener som godkjenningstjener. Winbind integrerer også rent med PAM og NSS. Dette gjør det mulig å sette opp Linux-maskiner der alle brukere av et Windows-domene automatisk får en konto.

en: More information can be found in the <filename>/usr/share/doc/libpam-winbind/examples/pam_winbind/</filename> directory of the <emphasis role="pkg">libpam-winbind</emphasis> package.
nb-NO: Mer informasjon finnes i <filename>/usr/share/doc/libpam-winbind/examples/pam_winbind/</filename>-katalogen til <emphasis role="pkg">libpam-winbind</emphasis>-pakken.

en: Configuring with <command>debconf</command>
nb-NO: Oppsett med <command>debconf</command>

en: <primary>Samba</primary><secondary>configuration</secondary>
nb-NO: <primary>Samba</primary><secondary>oppsett</secondary>

en: On first installation the only piece of required information is the name of the workgroup where the Samba server will belong (the answer is <literal>FALCOTNET</literal> in our case).
nb-NO: Ved første den eneste nødvendig informasjon er navnet på arbeidsgruppen som Samba-tjeneren vil tilhøre (svaret i vårt tilfelle er <literal>FALCOTNET</literal>).

en: In case of a package update (from the old stable Debian version) or if the SMB server has already been configured to use a WINS server (<literal>wins server</literal>), the package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server.
nb-NO: Med en pakkeoppdatering (fra den gamle stabile Debian-versjonen) eller hvis SMB-tjeneren allerede er satt opp til å bruke en WINS-tjener (<literal>wins server</literal>), foreslår pakken også å identifisere WINS-tjeneren ut fra opplysninger gitt av DHCP-bakgrunnsprosessen. Falcot Corp-administratorene forkastet dette alternativet, ettersom de har til hensikt å bruke Samba-tjeneren som WINS-tjener.

en: Configuring Manually
nb-NO: Manuelt oppsett

en: Changes to <filename>smb.conf</filename>
nb-NO: Forandringer i <filename>smb.conf</filename>

en: The requirements at Falcot require other options to be modified in the <filename>/etc/samba/smb.conf</filename> configuration file. The following excerpts summarize the changes that were effected in the <literal>[global]</literal> section.
nb-NO: Kravene hos Falcot forutsetter også endringer i andre valg i <filename>/etc/samba/smb.conf</filename>. Følgende utdrag oppsummerer de endringene som ble berørt i <literal>[global]</literal>-seksjonen.

en: This is the default value for this parameter; however, since it is central to the Samba configuration, filling it explicitly is recommended. Each user must authenticate before accessing any share.
nb-NO: Dette er standardverdien for denne parameteren; men siden den er sentral i Samba-oppsettet, anbefales det å fylle den inn eksplisitt. Hver bruker må godkjennes før noen deling.

en: Adding Users
nb-NO: Å legge til brukere

en: <primary>Samba</primary><secondary>add users</secondary>
nb-NO: <primary>Samba</primary><secondary>legg til brukere</secondary>

en: Each Samba user needs an account on the server; the Unix accounts must be created first, then the user needs to be registered in Samba's database. The Unix step is done quite normally (using <command>adduser</command> for instance).
nb-NO: Hver Samba-bruker trenger en konto på tjeneren; Unix-kontoer må opprettes først, deretter må brukeren bli registrert i Sambas database. Unix-trinnet utføres ganske vanlig (ved hjelp <command>adduser</command> for eksempel).

en: Adding an existing user to the Samba database is a matter of running the <command>smbpasswd -a <replaceable>user</replaceable></command> command; this command asks for the password interactively.
nb-NO: Å legge til en eksisterende bruker til Samba-databasen er et spørsmål om å kjøre <command>smbpasswd -a <replaceable>bruker</replaceable></command>-kommandoen; denne kommandoen ber interaktivt om passordet.

en: A user can be deleted with the <command>smbpasswd -x <replaceable>user</replaceable></command> command. A Samba account can also be temporarily disabled (with <command>smbpasswd -d <replaceable>user</replaceable></command>) and re-enabled later (with <command>smbpasswd -e <replaceable>user</replaceable></command>).
nb-NO: En bruker kan bli slettet med <command>smbpasswd -x <replaceable>bruker</replaceable></command>-kommandoen. En Samba-konto kan også midlertidig bli deaktivert (med <command>smbpasswd -d <replaceable>bruker</replaceable></command>), og reaktivert senere (med <command>smbpasswd -e <replaceable>bruker</replaceable></command>).

en: Samba Client
nb-NO: Samba-klient

en: <primary>Samba</primary><secondary>client</secondary>
nb-NO: <primary>Samba</primary><secondary>klient</secondary>

en: The client features in Samba allow a Linux machine to access Windows shares and shared printers. The required programs are available in the <emphasis role="pkg">cifs-utils</emphasis> and <emphasis role="pkg">smbclient</emphasis> packages.
nb-NO: Klient-funksjonene i Samba tillater en Linux-maskin å få tilgang til Windows-delinger og delte skrivere. De nødvendige programmene er tilgjengelig i <emphasis role="pkg">cifs-utils</emphasis> og <emphasis role="pkg">smbclient</emphasis>-pakkene.

en: The <command>smbclient</command> Program
nb-NO: Programmet <command>smbclient</command>

en: The <command>smbclient</command> program queries SMB servers. It accepts a <literal>-U <replaceable>user</replaceable></literal> option, for connecting to the server under a specific identity. <command>smbclient //<replaceable>server</replaceable>/<replaceable>share</replaceable></command> accesses the share in an interactive way similar to the command-line FTP client. <command>smbclient -L <replaceable>server</replaceable></command> lists all available (and visible) shares on a server.
nb-NO: Programmet <command>smbclient</command> forespør SMB-tjenere. Det aksepterer et <literal>-U <replaceable>bruker</replaceable></literal>-alternativ, for å koble til tjeneren med en bestemt identitet. <command>smbclient //<replaceable>server</replaceable>/<replaceable>dele</replaceable></command> åpner for delingen interaktivt på en måte lik kommandolinje FTP-klienten. <command>smbclient -L <replaceable>server</replaceable></command> lister opp alle tilgjengelige (og synlige) delinger på en tjener.

en: Mounting Windows Shares
nb-NO: Montere Windows-delinger

en: The <command>mount</command> command allows mounting a Windows share into the Linux filesystem hierarchy (with the help of <command>mount.cifs</command> provided by <emphasis role="pkg">cifs-utils</emphasis>).
nb-NO: Kommandoen <command>mount</command> tillater montering av en Windows-deling inn i Linux-filsystemhierarki (ved hjelp av <command>mount.cifs</command> levert av <emphasis role="pkg">cifs-utils</emphasis>).

en: Mounting a Windows share
nb-NO: Å montere en Windows-deling

en: <primary>Samba</primary><secondary>mount</secondary>
nb-NO: <primary>Samba</primary><secondary>montering</secondary>

en: The <filename>/etc/smb-credentials</filename> file (which must not be readable by users) has the following format:
nb-NO: Fil <filename>/etc/smb-credentials</filename> (som ikke må være lesbar av brukere) har følgende format:

en: <primary>Samba</primary><secondary>credentials</secondary>
nb-NO: <primary>Samba</primary><secondary>innloggingsinformasjon</secondary>

en: 
    username = <replaceable>user</replaceable>
    password = <replaceable>password</replaceable>
nb-NO: 
    username = <replaceable>bruker</replaceable>
    password = <replaceable>passord</replaceable>

en: Other options can be specified on the command-line; their full list is available in the <citerefentry><refentrytitle>mount.cifs</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page. Two options in particular can be interesting: <literal>uid</literal> and <literal>gid</literal> allow forcing the owner and group of files available on the mount, so as not to restrict access to root.
nb-NO: Andre alternativer kan spesifiseres på kommandolinjen; den fullstendige listen er tilgjengelig i <citerefentry><refentrytitle>mount.cifs</refentrytitle> <manvolnum>1</manvolnum></citerefentry>-manulaside. Spesielt to alternativer kan være interessante: <literal>uid</literal> og <literal>gid</literal> som tillater å tvinge eieren og gruppen filer som er tilgjengelig i monteringen, for ikke å begrense adgangen til rot.

en: A mount of a Windows share can also be configured in <filename>/etc/fstab</filename>:
nb-NO: En montering av en Windows-deling kan også settes opp i <filename>/etc/fstab</filename>:

en: 
    //<replaceable>server</replaceable>/shared /shared cifs credentials=/etc/smb-credentials
nb-NO: 
    //<replaceable>tjener</replaceable>/shared /shared cifs credentials=/etc/smb-credentials

en: Printing on a Shared Printer
nb-NO: Å skrive ut på en delt skriver

en: CUPS is an elegant solution for printing from a Linux workstation to a printer shared by a Windows machine. When the <emphasis role="pkg">smbclient</emphasis> is installed, CUPS allows installing Windows shared printers automatically.
nb-NO: CUPS er en elegant løsning for utskrift fra en Linux-arbeidsstasjon til en skriver som deles av en Windows-maskin. Når <emphasis role="pkg">smbclient</emphasis> er installert, tillater CUPS automatisk installasjon av Windows-delte skrivere.

en: <primary>printing</primary><secondary>network</secondary>
nb-NO: <primary>skrive ut</primary><secondary>nettverk</secondary>

en: <primary>Samba</primary><secondary>shared printers</secondary>
nb-NO: <primary>Samba</primary><secondary>delte skrivere</secondary>

en: Here are the required steps:
nb-NO: Her er skrittene som kreves:

en: Enter the CUPS configuration interface: <literal>http://localhost:631/admin</literal>
nb-NO: Bruk CUPS oppsettsgrensesnittet:<literal>http://localhost:631/admin</literal>

en: Click on “Add Printer”.
nb-NO: Klikk på «Legg til skriver».

en: Choose the printer device, pick “Windows Printer via SAMBA”.
nb-NO: Velg skriverenheten, plukk ut «Windows Printer via SAMBA».

en: Enter the connection URI for the network printer. It should look like the following:
nb-NO: Bruk tilkoblings-URI-en (angi URI) for nettverksskriveren. Den skal se ut som følger:

en: <literal>smb://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>/<replaceable>printer</replaceable></literal>.
nb-NO: <literal>smb://<replaceable>bruker</replaceable>:<replaceable>passord</replaceable>@<replaceable>server</replaceable>/<replaceable>skriver</replaceable></literal>.

en: Enter the name that will uniquely identify this printer. Then enter the description and location of the printer. Those are the strings that will be shown to end users to help them identify the printers.
nb-NO: Skriv inn navnet som unikt identifiserer denne skriveren. Deretter skriver du inn beskrivelsen og plasseringen av skriveren. De er strengene som skal vises til sluttbrukere for å hjelpe dem med å identifisere skriverne.

en: Indicate the manufacturer/model of the printer, or directly provide a working printer description file (PPD).
nb-NO: Indiker produsenten/skrivermodellen, eller lever/gi direkte en skriverbeskrivelsesfil (PPD (PostScript Printer Description)) som virker.

en: Voilà, the printer is operational!
nb-NO: Voilà, skriveren er operativ!

en: HTTP/FTP Proxy
nb-NO: HTTP/FTP-mellomtjener

en: An HTTP/FTP proxy acts as an intermediary for HTTP and/or FTP connections. Its role is twofold:
nb-NO: En HTTP/FTP-mellomtjener fungerer som et mellomledd for HTTP- og/eller FTP-tilkoblinger. Dens rolle er todelt:

en: Caching: recently downloaded documents are copied locally, which avoids multiple downloads.
nb-NO: Hurtiglager: Nylig nedlastede dokumenter kopieres lokalt, noe som hindrer flere/multiple nedlastinger.

en: Filtering server: if use of the proxy is mandated (and outgoing connections are blocked unless they go through the proxy), then the proxy can determine whether or not the request is to be granted.
nb-NO: Filtreringstjener: Kreves bruk av mellomtjeneren (og utgående tilkoblinger blokkeres med mindre de går gjennom mellomtjeneren), da kan mellomtjeneren avgjøre om forespørselen skal imøtekommes.

en: <primary>HTTP/FTP proxy</primary>
nb-NO: <primary>HTTP/FTP-proxy</primary>

en: <primary>proxy cache</primary>
nb-NO: <primary>mellomtjener lager</primary>

en: Falcot Corp selected Squid as their proxy server.
nb-NO: Falcot Corp valgte Squid som sin mellomtjener.

en: Installing
nb-NO: Installasjon

en: <primary>Squid</primary><secondary>installation</secondary>
nb-NO: <primary>Squid</primary><secondary>installasjon</secondary>

en: Prior to installing, care should be taken to check that the system can identify its own complete name: the <command>hostname -f</command> must return a fully-qualified name (including a domain). If it does not, then the <filename>/etc/hosts</filename> file should be edited to contain the full name of the system (for instance, <literal>arrakis.falcot.com</literal>). The official computer name should be validated with the network administrator in order to avoid potential name conflicts.
nb-NO: Før du installerer, er det viktig å ta hensyn til at systemet kan identifisere sitt eget fullstendige navn: <command>hostname -f</command> må returnere et fullt kvalifisert navn (inkludert et domene). Hvis den ikke gjør det, så skal <filename>/etc/hosts</filename>-filen redigeres til å inneholde fullt navn på systemet (for eksempel <literal>arrakis.falcot.com</literal>). Det offisielle navnet på datamaskinen skal godkjennes av nettverksadministratoren for å unngå potensielle navnekonflikter.

en: Configuring a Cache
nb-NO: Oppsett av et hurtiglager

en: Enabling the caching server feature is a simple matter of editing the <filename>/etc/squid/squid.conf</filename> configuration file and allowing machines from the local network to run queries through the proxy. The following example shows the modifications made by the Falcot Corp administrators:
nb-NO: Å aktivere funksjonen til hurtiglagringstjener er så enkelt som å redigere <filename>/etc/squid/squid.conf</filename>-oppsettsfilen, og la maskinene fra det lokale nettverket kjøre forespørsler gjennom mellomtjeneren. Det følgende eksemplet viser modifikasjonene Falcot Corp-administratorene har gjort:

en: The <filename>/etc/squid/squid.conf</filename> file (excerpts)
nb-NO: <filename>/etc/squid/squid.conf</filename>-filen (utdrag)

en: Configuring a Filter
nb-NO: Oppsett av et filter

en: <command>squid</command> itself does not perform the filtering; this action is delegated to <command>squidGuard</command>. The former must then be configured to interact with the latter. This involves adding the following directive to the <filename>/etc/squid/squid.conf</filename> file:
nb-NO: <command>squid</command> utfører ikke filtreringen selv; den er delegert til <command>squidGuard</command>. Den førstnevnte må da være satt opp til å samvirke med den sistnevnte. Dette innebærer å legge følgende direktiv til <filename>/etc/squid/squid.conf</filename>-filen:

en: The working database must be regenerated with <command>update-squidguard</command> after each change of the <command>squidGuard</command> configuration file (or one of the lists of domains or URLs it mentions). The configuration file syntax is documented on the following website: <ulink type="block" url="http://www.squidguard.org/Doc/configure.html" />
nb-NO: Den gjeldende databasen må regenereres med <command>update-squidguard</command> etter hver forandring i <command>squidGuard</command>-oppsettsfilen (eller en av de lister over domener eller nettadresser den nevner). Oppsettsfil-syntaksen er dokumentert på den følgende nettsiden: <ulink type="block" url="http://www.squidguard.org/Doc/configure.html" />

en: <emphasis>ALTERNATIVE</emphasis> E2guardian (a DansGuardian Fork)
nb-NO: <emphasis>ALTERNATIV</emphasis> E2guardian (en forgrening av DansGuardian)

en: LDAP Directory
nb-NO: LDAP-mappe

en: <primary>directory, LDAP</primary>
nb-NO: <primary>mappe, LDAP</primary>

en: OpenLDAP is an implementation of the LDAP protocol; in other words, it is a special-purpose database designed for storing directories. In the most common use case, using an LDAP server allows centralizing management of user accounts and the related permissions. Moreover, an LDAP database is easily replicated, which allows setting up multiple synchronized LDAP servers. When the network and the user base grows quickly, the load can then be balanced across several servers.
nb-NO: OpenLDAP er en implementering av LDAP-protokollen; med andre ord, den er en database med spesialformål å lagre kataloger. I det mest vanlige brukertilfellet, tillater bruk av en LDAP-tjener sentral forvaltning av brukerkontoer og de tilhørende rettighetene. Dessuten er det lett å kopiere LDAP-databasen, som tillater oppsett av flere synkroniserte LDAP-tjenere. Når nettverket og brukerbasen vokser raskt, kan lasten så bli balansert over flere tjenere.

en: LDAP data is structured and hierarchical. The structure is defined by “schemas” which describe the kind of objects that the database can store, with a list of all their possible attributes. The syntax used to refer to a particular object in the database is based on this structure, which explains its complexity.
nb-NO: LDAP-data er strukturert og hierarkisk. Strukturen er definert av «skjemaer», som beskriver den type objekter som databasen kan lagre, med en liste over alle de mulige egenskapene deres. Syntaksen brukes for å referere til et bestemt objekt i databasen basert på denne strukturen, noe som forklarer kompleksiteten.

en: The <emphasis role="pkg">slapd</emphasis> package contains the OpenLDAP server. The <emphasis role="pkg">ldap-utils</emphasis> package includes command-line tools for interacting with LDAP servers.
nb-NO: Pakken <emphasis role="pkg">slapd</emphasis> inneholder den åpne OpenLDAP-tjeneren. Pakken <emphasis role="pkg">ldap-utils</emphasis> inneholder kommandolinjeverktøy for samhandling med LDAP-tjenere.

en: Installing <emphasis role="pkg">slapd</emphasis> usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple <command>dpkg-reconfigure slapd</command> will let you reconfigure the LDAP database with more details:
nb-NO: Å installere <emphasis role="pkg">slapd</emphasis> spør vanligvis bare for administratorens passord, og det er usannsynlig at den resulterende databasen dekker dine behov. Heldigvis, en enkel <command>dpkg-reconfigure slapd</command> vil la deg sette opp LDAP-databasen med flere detaljer:

en: Omit OpenLDAP server configuration? No, of course, we want to configure this service.
nb-NO: Utelate OpenLDAP-tjeneroppsettet? Nei, selvfølgelig ønsker vi å sette opp denne tjenesten.

en: DNS domain name: “<literal>falcot.com</literal>”.
nb-NO: DNS-domenenavn: «<literal>falcot.com</literal>».

en: Organization name: “Falcot Corp”.
nb-NO: Organisasjonsnavn: «Falcot Corp».

en: An administrative passwords needs to be typed in.
nb-NO: Et administrativt passord må skrives inn.

en: Database backend to use: “MDB”.
nb-NO: Bruk database-backend: «MDB».

en: Do you want the database to be removed when <emphasis role="pkg">slapd</emphasis> is purged? No. No point in risking losing the database in case of a mistake.
nb-NO: Ønsker du at databasen skal fjernes når <emphasis role="pkg">slapd</emphasis> tvinges? Nei. Det er ingen vits i å risikere å miste databasen på grunn av en feil.

en: Move old database? This question is only asked when the configuration is attempted while a database already exists. Only answer “yes” if you actually want to start again from a clean database, for instance if you run <command>dpkg-reconfigure slapd</command> right after the initial installation.
nb-NO: Flytte den gamle databasen? Dette spørsmålet blir bare spurt når oppsettet er forsøkt, og en database allerede eksisterer. Bare svar «ja» hvis du faktisk ønsker å starte på nytt med en ren database; for eksempel hvis du kjører <command>dpkg-reconfigure slapd</command> rett etter den første installasjonen.

en: <emphasis>BACK TO BASICS</emphasis> LDIF format
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> LDIF-format

en: An LDIF file (<emphasis>LDAP Data Interchange Format</emphasis>) is a portable text file describing the contents of an LDAP database (or a portion thereof); this can then be used to inject the data into any other LDAP server.
nb-NO: En LDIF-file (<emphasis>LDAP Data Interchange Format</emphasis>) er en flyttbar tekstfil som beskriver innholdet i en LDAP-database (eller en del av den); denne kan så brukes til å legge inn (inject) data inn i en hvilken som helst annen LDAP-tjener.

en: A minimal database is now configured, as demonstrated by the following query:
nb-NO: Nå er en minimal database satt opp, som demonstrert av følgende spørring:

en: The query returned two objects: the organization itself, and the administrative user.
nb-NO: Spørringen returnerte to objekter: Organisasjonen selv, og den administrative brukeren.

en: Filling in the Directory
nb-NO: Å fylle ut mappen

en: Since an empty database is not particularly useful, we are going to inject into it all the existing directories; this includes the users, groups, services and hosts databases.
nb-NO: Ettersom en tom database ikke er spesielt nyttig, har vi tenkt å legge inn (injisere) i den i alle de eksisterende katalogene; Dette inkluderer brukerne, gruppene, tjenestene og vertsdatabasene.

en: The <emphasis role="pkg">migrationtools</emphasis> package provides a set of scripts dedicated to extract data from the standard Unix directories (<filename>/etc/passwd</filename>, <filename>/etc/group</filename>, <filename>/etc/services</filename>, <filename>/etc/hosts</filename> and so on), convert this data, and inject it into the LDAP database.
nb-NO: Pakken <emphasis role="pkg">migrationtools</emphasis> inneholder et sett skript øremerket til å hente ut data fra standard Unix-kataloger (<filename>/etc/passwd</filename>, <filename>/etc/group</filename>, <filename>/etc/services</filename>, <filename>/etc/hosts</filename>, og så videre), konvertere disse dataene, og sette den inn i LDAP-databasen.

en: Once the package is installed, the <filename>/etc/migrationtools/migrate_common.ph</filename> must be edited; the <varname>IGNORE_UID_BELOW</varname> and <varname>IGNORE_GID_BELOW</varname> options need to be enabled (uncommenting them is enough), and <varname>DEFAULT_MAIL_DOMAIN</varname>/<varname>DEFAULT_BASE</varname> need to be updated.
nb-NO: Så snart pakken er installert, må <filename>/etc/migrationtools/migrate_common.ph</filename> redigeres; <varname>IGNORE_UID_BELOW</varname> og <varname>IGNORE_GID_BELOW</varname>-valgene må aktiveres (å avkommentere dem er nok), og <varname>DEFAULT_MAIL_DOMAIN</varname>/<varname>DEFAULT_BASE</varname> trenger oppdatering.

en: The actual migration operation is handled by the <command>migrate_all_online.sh</command> command, as follows:
nb-NO: Selve overføringsoperasjonen håndteres av <command>migrate_all_online.sh</command>-kommandoen, som følger:

en: The <command>migrate_all_online.sh</command> asks a few questions about the LDAP database into which the data is to be migrated. <xref linkend="tab-migrate-all" xrefstyle="select: label nopage" /> summarizes the answers given in the Falcot use-case.
nb-NO: <command>migrate_all_online.sh</command> stiller noen få spørsmål om LDAP-databasen som dataene skal overføres til. <xref linkend="tab-migrate-all" xrefstyle="select: label nopage" /> oppsummerer svarene fra Falcots brukereksempel.

en: Answers to questions asked by the <command>migrate_all_online.sh</command> script
nb-NO: Svar på spørsmål forespurt av <command>migrate_all_online.sh</command>-skriptet

en: Question
nb-NO: Spørsmål

en: Answer
nb-NO: Svar

en: X.500 naming context
nb-NO: X.500 navnekontekst

en: LDAP server hostname
nb-NO: Vertsnavnet på LDAP-serveren

en: Manager DN
nb-NO: Manager-DN

en: Bind credentials
nb-NO: Tilknytningsreferanser

en: the administrative password
nb-NO: det administrative passordet

en: Create DUAConfigProfile
nb-NO: Lag DUAConfigProfile

en: no
nb-NO: nei

en: <emphasis>TOOL</emphasis> Browsing an LDAP directory
nb-NO: <emphasis>VERKTØY</emphasis> Søke i en LDAP-mappe

en: The <command>jxplorer</command> command (in the package of the same name) is a graphical tool allowing to browse and edit an LDAP database. It is an interesting tool that provides an administrator with a good overview of the hierarchical structure of the LDAP data.
nb-NO: Kommandoen <command>jxplorer</command> (i pakken med samme navn) er et grafisk verktøy som tillater å bla gjennom og redigere en LDAP-database. Dette er et interessant verktøy som gir en administrator en god oversikt over den hierarkiske strukturen i LDAP-dataene.

en: Also note the use of the <literal>-c</literal> option to the <command>ldapadd</command> command; this option requests that processing doesn't stop in case of error. Using this option is required because converting the <filename>/etc/services</filename> often generates a few errors that can safely be ignored.
nb-NO: Legg også merke til bruken av <literal>-c</literal>-valget til <command>ldapadd</command>-kommandoen; dette alternativet ber om at prosessen ikke stopper i tilfelle feil. Å bruke dette alternativet kreves fordi å konvertere <filename>/etc/services</filename> ofte generer noen få feil som trygt kan ignoreres.

en: Managing Accounts with LDAP
nb-NO: Å håndtere kontoer med LDAP

en: Now the LDAP database contains some useful information, the time has come to make use of this data. This section focuses on how to configure a Linux system so that the various system directories use the LDAP database.
nb-NO: Nå når LDAP-databasen inneholder en del nyttig informasjon, er tiden kommet for å gjøre bruk av disse dataene. I denne seksjonen skal vi se på hvordan du setter opp et Linux-system, slik at de ulike systemmappene bruker LDAP-databasen.

en: Configuring NSS
nb-NO: Oppsett av NSS

en: The NSS system (Name Service Switch, see sidebar <xref linkend="sidebar.intro-nss" />) is a modular system designed to define or fetch information for system directories. Using LDAP as a source of data for NSS requires installing the <emphasis role="pkg">libnss-ldap</emphasis> package. Its installation asks a few questions; the answers are summarized in <xref linkend="tab-libnss-ldap" xrefstyle="select: label nopage" />.
nb-NO: NSS-systemet (Name Service Switch, se sidestolpe <xref linkend="sidebar.intro-nss" />) er et modulært system utformet for å definere eller hente informasjon for systemmapper. Med LDAP som datakilde krever NSS installasjon av <emphasis role="pkg">libnss-ldap</emphasis>-pakken. Installasjonen av den stiller noen få spørsmål; svarene er oppsummert i <xref linkend="tab-libnss-ldap" xrefstyle="select: label nopage" />.

en: Distinguished name of the search base
nb-NO: Øremerket navn for søkerbasen

en: LDAP version to use
nb-NO: LDAP-versjon som skal brukes

en: LDAP account for root
nb-NO: LDAP-konto for rot

en: LDAP root account password
nb-NO: LDAP-passord for rotkonto

en: Allow LDAP admin account behave like local root?
nb-NO: Å tillate LDAP-adminkontoen oppføre seg som lokal rot?

en: <literal>yes</literal>
nb-NO: <literal>ja</literal>

en: Does the LDAP database require login?
nb-NO: Krever LDAP-databasen innlogging?

en: The <filename>/etc/nsswitch.conf</filename> file then needs to be modified, so as to configure NSS to use the freshly-installed <command>ldap</command> module. You can use the example provided in <filename>/usr/share/doc/libnss-ldap/examples/nsswitch.ldap</filename> or edit your existing configuration.
nb-NO: Filen <filename>/etc/nsswitch.conf</filename> må deretter endres, for å sette opp NSS til å bruke den nettopp installerte <command>ldap</command>-modulen. Du kan bruke eksemplet fra <filename>/usr/share/doc/libnss-ldap/examples/nsswitch.ldap</filename> eller redigere ditt eksisterende oppsett.

en: The <filename>/etc/nsswitch.conf</filename> file
nb-NO: Filen <filename>/etc/nsswitch.conf</filename>

en: The <command>ldap</command> module is usually inserted before others, and it will therefore be queried first. The notable exception is the <literal>hosts</literal> service since contacting the LDAP server requires consulting DNS first (to resolve <literal>ldap.falcot.com</literal>). Without this exception, a hostname query would try to ask the LDAP server; this would trigger a name resolution for the LDAP server, and so on in an infinite loop.
nb-NO: Modulen <command>ldap</command> er vanligvis satt inn før de andre, og den vil derfor spørres først. Unntaket å merke seg er <literal>hosts</literal>-tjenesten, siden LDAP-tjeneren krever å kontakte DNS først (for å løse <literal>ldap.falcot.com</literal>). Uten dette unntaket, ville en forespørsel om vertsnavn prøve å spørre LDAP-tjeneren; dette ville utløse et navneoppslag for LDAP-tjeneren, og så videre i en uendelig sløyfe.

en: If the LDAP server should be considered authoritative (and the local files used by the <command>files</command> module disregarded), services can be configured with the following syntax:
nb-NO: Hvis LDAP-tjeneren skal vurderes som autoritative (og de lokale filene som brukes av <command>files</command>-modulen ignoreres), kan tjenester settes opp med følgende syntaks:

en: <literal><replaceable>service</replaceable>: ldap [NOTFOUND=return] files</literal>.
nb-NO: <literal><replaceable>tjeneste</replaceable>: ldap [NOTFOUND=return] files</literal>.

en: If the requested entry does not exist in the LDAP database, the query will return a “not existing” reply even if the resource does exist in one of the local files; these local files will only be used when the LDAP service is down.
nb-NO: Hvis den forespurte oppføringen ikke finnes i LDAP-databasen, vil søket returnere et «ikke eksisterende» svar, selv om ressursen eksisterer i en av de lokale filene. Disse lokale filene vil bare bli brukt når LDAP-tjenesten er nede.

en: Configuring PAM
nb-NO: Oppsett av PAM

en: This section describes a PAM configuration (see sidebar <xref linkend="sidebar.intro-pam" />) that will allow applications to perform the required authentications against the LDAP database.
nb-NO: Denne delen beskriver et PAM-oppsett (se sidestolpe <xref linkend="sidebar.intro-pam" />) som vil tillate programmer å utføre de nødvendige godkjenninger mot LDAP-databasen.

en: <emphasis>CAUTION</emphasis> Broken authentication
nb-NO: <emphasis>VÆR VARSOM</emphasis> Brutt godkjenning

en: Changing the standard PAM configuration used by various programs is a sensitive operation. A mistake can lead to broken authentication, which could prevent logging in. Keeping a root shell open is therefore a good precaution. If configuration errors occur, they can be then fixed and the services restarted with minimal effort.
nb-NO: Det er en følsom operasjon å endre den standard PAM-oppsett som brukes av ulike programmer. En feil kan føre til ødelagt godkjenning, noe som kan hindre innlogging. Å holde et rotskall åpent er derfor en god forholdsregel. Hvis det oppstår oppsettsfeil, kan de fikses, og tjenesten startes igjen med minimal innsats.

en: The LDAP module for PAM is provided by the <emphasis role="pkg">libpam-ldap</emphasis> package. Installing this package asks a few questions very similar to those in <emphasis role="pkg">libnss-ldap</emphasis>; some configuration parameters (such as the URI for the LDAP server) are even actually shared with the <emphasis role="pkg">libnss-ldap</emphasis> package. Answers are summarized in <xref linkend="tab-libpam-ldap" xrefstyle="select: label nopage" />.
nb-NO: LDAP-modulen for PAM leveres av <emphasis role="pkg">libpam-ldap</emphasis>-pakken. Å installere denne pakken stiller noen spørsmål som er svært lik dem i <emphasis role="pkg">libnss-ldap</emphasis>. Noen oppsettsparametere (for eksempel URI for LDAP-tjeneren) er faktisk delt med <emphasis role="pkg">libnss-ldap</emphasis>-pakken. Svarene er oppsummert i <xref linkend="tab-libpam-ldap" xrefstyle="select: label nopage" />.

en: Configuration of <emphasis>libpam-ldap</emphasis>
nb-NO: Oppsett av <emphasis>libpam-ldap</emphasis>

en: Allow LDAP admin account to behave like local root?
nb-NO: Tillate LDAP-administrasjonskontoen å oppføre seg som lokal rot?

en: Yes. This allows using the usual <command>passwd</command> command for changing passwords stored in the LDAP database.
nb-NO: Ja. Dette tilllater å bruke den vanlige <command>passwd</command>-kommandoen for å endre passord lagret i LDAP-databasen.

en: Does the LDAP database require logging in?
nb-NO: Krever LDAP-databasen innlogging?

en: the LDAP database administrative password
nb-NO: LDAP-databasens administrative passord

en: PAM profiles to enable:
nb-NO: PAM-profiler å aktivere:

en: LDAP Authentication is among the enabled profiles
nb-NO: LDAP-identitetsbekreftelse er blandt de aktiverte profilene

en: Installing <emphasis role="pkg">libpam-ldap</emphasis> automatically adapts the default PAM configuration defined in the <filename>/etc/pam.d/common-auth</filename>, <filename>/etc/pam.d/common-password</filename> and <filename>/etc/pam.d/common-account</filename> files. This mechanism uses the dedicated <command>pam-auth-update</command> tool (provided by the <emphasis role="pkg">libpam-runtime</emphasis> package). This tool can also be run by the administrator should they wish to enable or disable PAM modules.
nb-NO: Installering av <emphasis role="pkg">libpam-ldap</emphasis> tilpasser automatisk standard PAM-oppsettet som er definert i <filename>/etc/pam.d/common-auth</filename>, <filename>/etc/pam.d/common-password</filename> og <filename>/etc/pam.d/common-account</filename>-filene. Denne mekanisme bruker det øremerkede <command>pam-auth-update</command>-verktøyet (levert av <emphasis role="pkg">libpam-runtime</emphasis>-pakken). Dette verktøyet kan også kjøres av administratoren dersom de ønsker å aktivere eller deaktivere PAM-moduler.

en: Securing LDAP Data Exchanges
nb-NO: Å sikre LDAP-datautveksling

en: <primary>LDAP</primary><secondary>secure</secondary>
nb-NO: <primary>LDAP</primary><secondary>sikre</secondary>

en: By default, the LDAP protocol transits on the network as cleartext; this includes the (encrypted) passwords. Since the encrypted passwords can be extracted from the network, they can be vulnerable to dictionary-type attacks. This can be avoided by using an extra encryption layer; enabling this layer is the topic of this section.
nb-NO: Som standard transporterer LDAP-protokollen på nettverket i klartekst. Dette inkluderer (krypterte) passord. Ettersom de krypterte passordene kan være hentet fra nettverket, kan de være sårbare for type ordbokangrep. Dette kan unngås ved hjelp av et ekstra krypteringslag; å aktivere dette laget er tema for denne seksjonen.

en: Configuring the Server
nb-NO: Oppsett av tjenermaskinen

en: <primary><foreignphrase>OpenSSL</foreignphrase></primary><secondary>creating keys</secondary>
nb-NO: <primary><foreignphrase>OpenSSL</foreignphrase></primary><secondary>lage nøkler</secondary>

en: <primary>key pair</primary>
nb-NO: <primary>nøkkelpar</primary>

en: The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse <emphasis>easy-rsa</emphasis> to generate it (see <xref linkend="sect.easy-rsa" />). Running <command>./easyrsa build-server-full ldap.falcot.com nopass</command> will ask you about the “common name”. The answer to that question <emphasis>must</emphasis> be the fully-qualified hostname for the LDAP server; in our case, <literal>ldap.falcot.com</literal>.
nb-NO: Det første trinnet er å opprette et nøkkelpar (bestående av en offentlig nøkkel og en privat nøkkel) for LDAP-tjeneren. Falcot-administratorene gjenbruker <emphasis>easy-rsa</emphasis> for å generere dem (se <xref linkend="sect.easy-rsa" />). Kjøring av <command>./easyrsa build-server-full ldap.falcot.com nopass</command> vil spørre deg om "felles navnet". Svaret på dette spørsmålet <emphasis>må</emphasis> være det fullstendige vertsnavnet for LDAP-tjeneren; i vårt tilfelle, <literal>ldap.falcot.com</literal>.

en: This command creates a certificate in the <filename>pki/issued/ldap.falcot.com.crt</filename> file; the corresponding private key is stored in <filename>pki/private/ldap.falcot.com.key</filename>.
nb-NO: Denne kommandoen lager et sertifikat i filen <filename>pki/issued/ldap.falcot.com.crt</filename> , og den tilhørende private nøkkelen lagres i <filename>pki/private/ldap.falcot.com.key</filename>.

en: Now these keys have to be installed in their standard location, and we must make sure that the private file is readable by the LDAP server which runs under the <literal>openldap</literal> user identity:
nb-NO: Nå må disse nøklene være installert med sin standard plassering, og vi må sørge for at den private filen er lesbar av LDAP-tjeneren, som kjører med <literal>openldap</literal>-brukerindentiteten:

en: The <command>slapd</command> daemon also needs to be told to use these keys for encryption. The LDAP server configuration is managed dynamically: the configuration can be updated with normal LDAP operations on the <literal>cn=config</literal> object hierarchy, and the server updates <filename>/etc/ldap/slapd.d</filename> in real time to make the configuration persistent. <command>ldapmodify</command> is thus the right tool to update the configuration:
nb-NO: Bakgrunnsprosessen <command>slapd</command> må også få beskjed om å bruke disse nøklene/tastene til kryptering. LDAP-tjeneroppsettet styres dynamisk: oppsettet kan oppdateres med normale LDAP-operasjoner på <literal>cn=config</literal>-objekthierarki, og tjeneroppdateringer på <filename>/etc/ldap/slapd.d</filename> i sann tid for å gjøre oppsettet varig. <command>ldapmodify</command> er dermed det riktige verktøyet for å oppdatere oppsettet:

en: Configuring <command>slapd</command> for encryption
nb-NO: Oppsett av <command>slapd</command> for kryptering

en: <emphasis>TOOL</emphasis> <command>ldapvi</command> to edit an LDAP directory
nb-NO: <emphasis>VERKTØY</emphasis> <command>ldapvi</command> for å redigere en LDAP-mappe

en: It is thus a convenient way to update the configuration of the LDAP server, simply by editing the <literal>cn=config</literal> hierarchy.
nb-NO: Dette er derfor en praktisk måte å oppdatere LDAP-tjenerens oppsett, ganske enkelt ved å redigere <literal>cn=config</literal>-hierarkiet.

en: The last step for enabling encryption involves changing the <varname>SLAPD_SERVICES</varname> variable in the <filename>/etc/default/slapd</filename> file. We'll play it safe and disable unsecured LDAP altogether.
nb-NO: Det siste trinnet for å aktivere kryptering innebærer å endre <varname>SLAPD_SERVICES</varname>-variabelen i <filename>/etc/default/slapd</filename>-filen. Vi skal gjøre det trygt, og helt deaktivere usikret LDAP.

en: The <filename>/etc/default/slapd</filename> file
nb-NO: Filen <filename>/etc/default/slapd</filename>

en: Configuring the Client
nb-NO: Oppsett av klienten

en: On the client side, the configuration for the <emphasis>libpam-ldap</emphasis> and <emphasis>libnss-ldap</emphasis> modules needs to be modified to use an <literal>ldaps://</literal> URI.
nb-NO: På klientsiden trenger oppsettet for <emphasis>libpam-ldap</emphasis> og <emphasis>libnss-ldap</emphasis>-modulene å bli modifisert til å bruke en <literal>ldaps://</literal>-URI.

en: Last but not least, the default LDAP URI and default base DN used by the various command line tools can be modified in <filename>/etc/ldap/ldap.conf</filename>. This will save quite some typing.
nb-NO: Sist men ikke minst kan standard LDAP URI og standard base DN, brukt av de ulike kommandolinjeverktøyene, endres i <filename>/etc/ldap/ldap.conf</filename>. Dette vil spare ganske mye skriving.

en: The <filename>/etc/ldap/ldap.conf</filename> file
nb-NO: Filen <filename>/etc/ldap/ldap.conf</filename>

en: Real-Time Communication Services
nb-NO: Sanntids kommunikasjonstjenester

en: <primary>Real-Time Communication</primary><see>RTC</see>
nb-NO: <primary>Sanntidskommunikasjon (Real-Time Communication)</primary><see>RTC</see>

en: Real-Time Communication (RTC) services include voice, video/webcam, instant messaging (IM) and desktop sharing. This chapter gives a brief introduction to three of the services required to operate RTC, including a TURN server, SIP server and XMPP server. Comprehensive details of how to plan, install and manage these services are available in the Real-Time Communications Quick Start Guide which includes examples specific to Debian. <ulink type="block" url="https://rtcquickstart.org" />
nb-NO: Real-Time Communication (RTC)-tjenester (sanntids kommunikasjonstjenester) inkluderer tale, video/nettkamera, lynmelding (IM) og skrivebordsdeling. Dette kapitlet gir en kort innføring i tre av de tjenester som kreves for å drive RTC, omfattende en TURN-tjener, SIP-tjener og XMPP-tjener. Omfattende detaljinformasjon om hvordan planlegge, installere og administrere disse tjenestene er tilgjengelige i Real-Time Communications Quick Start Guide (Hurtigstartveiledning) som inneholder eksempler som er spesifikke for Debian. <ulink type="block" url="https://rtcquickstart.org" />

en: Both SIP and XMPP can provide the same functionality. SIP is slightly more well known for voice and video while XMPP is traditionally regarded as an IM protocol. In fact, they can both be used for any of these purposes. To maximize connectivity options, it is recommended to run both in parallel.
nb-NO: Både SIP og XMPP kan gi den samme funksjonaliteten. SIP er litt mer kjent for tale og video, mens XMPP er tradisjonelt ansett som en IM-protokoll. Faktisk kan begge anvendes for hvilke som helst av disse formålene. For å maksimere tilkoblingsmuligheter anbefales det å kjøre begge parallelt.

en: These services rely on X.509 certificates both for authentication and confidentiality purposes. See <xref linkend="sect.x509-cert" /> for more information.
nb-NO: Disse tjenestene er avhengige av X.509-sertifikater både for autentiserings- og konfidensialitetsformål. Se <xref linkend="sect.x509-cert" /> for mer informasjon.

en: DNS settings for RTC services
nb-NO: DNS-innstillinger for RTC-tjenester

en: 
    ; the server where everything will run
    server1            IN     A      198.51.100.19
    server1            IN     AAAA   2001:DB8:1000:2000::19
    
    ; IPv4 only for TURN for now, some clients are buggy with IPv6
    turn-server        IN     A      198.51.100.19
    
    ; IPv4 and IPv6 addresses for SIP
    sip-proxy          IN     A      198.51.100.19
    sip-proxy          IN     AAAA   2001:DB8:1000:2000::19
    
    ; IPv4 and IPv6 addresses for XMPP
    xmpp-gw            IN     A      198.51.100.19
    xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19
    
    ; DNS SRV and NAPTR for STUN / TURN
    _stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    _turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    @           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.
    
    ; DNS SRV and NAPTR records for SIP
    _sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
    @           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
    
    ; DNS SRV records for XMPP Server and Client modes:
    _xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
    _xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.
nb-NO: 
    ; tjenermaskinen der alt kommer til å kjøre
    server1            IN     A      198.51.100.19
    server1            IN     AAAA   2001:DB8:1000:2000::19
    
    ; Kun IPv4 for TURN akkurat nå, da noen klienter har problemer med IPv6
    turn-server        IN     A      198.51.100.19
    
    ; IPv4- og IPv6-adresser for SIP
    sip-proxy          IN     A      198.51.100.19
    sip-proxy          IN     AAAA   2001:DB8:1000:2000::19
    
    ; IPv4- og IPv6-adresser for XMPP
    xmpp-gw            IN     A      198.51.100.19
    xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19
    
    ; DNS SRV og NAPTR for STUN / TURN
    _stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    _turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    @           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.
    
    ; DNS SRV- og NAPTR-oppføringer for SIP
    _sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
    @           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
    
    ; DNS SRV-oppføringer for XMPP-tjener- og klient-modus:
    _xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
    _xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.

en: TURN Server
nb-NO: TURN-tjener

en: TURN is a service that helps clients behind NAT routers and firewalls to discover the most efficient way to communicate with other clients and to relay the media streams if no direct media path can be found. It is highly recommended that the TURN server is installed before any of the other RTC services are offered to end users.
nb-NO: TURN er en tjeneste som hjelper klientene bak NAT-rutere og brannmurer med å finne den mest effektive måten å kommunisere med andre klienter på, og for å formidle mediestrømmer hvis ingen direkte mediabane blir funnet. Det anbefales sterkt at TURN-tjeneren installeres før noen av de andre RTC-tjenestene tilbys til sluttbrukere.

en: <primary>TURN</primary><secondary>server</secondary>
nb-NO: <primary>TURN</primary><secondary>tjener</secondary>

en: TURN and the related ICE protocol are open standards. To benefit from these protocols, maximizing connectivity and minimizing user frustration, it is important to ensure that all client software supports ICE and TURN.
nb-NO: TURN og den tilhørende ICE-protokollen er åpne standarder. For å dra nytte av disse protokollene, maksimere tilkoblingsmuligheter, og minimere brukerfrustrasjon, er det viktig å sikre at alle klientprogramvarene støtter ICE og TURN.

en: For the ICE algorithm to work effectively, the server must have two public IPv4 addresses.
nb-NO: For å få ICE-algoritmene til å fungere effektivt må tjeneren ha to offentlige IPv4-adresser.

en: Install the <emphasis role="pkg">coturn</emphasis> package and edit the <filename>/etc/turnserver.conf</filename> configuration file. By default, a SQLite database is configured in <filename>/var/db/turndb</filename> for user account settings, but PostgreSQL, MySQL or Redis can be set up instead if preferred. The most important thing to do is insert the IP addresses of the server.
nb-NO: Installer pakken <emphasis role="pkg">coturn</emphasis> og rediger oppsettfilen <filename>/etc/turnserver.conf</filename>. Som standard er en SQLite-database satt opp i <filename>/var/db/turndb</filename> for brukerkontoinnstillinger, men PostgreSQL, MySQL eller Redis kan settes opp i stedet hvis ønskelig. Det viktigste er å sette inn IP-adressene til tjenerne.

en: By default, the TURN server uses anonymous access. We have to add the users we want to use:
nb-NO: Som standard bruker TURN-tjeneren anonym tilgang. Vi må legge til de brukerne vi vil bruke:

en: We use the argument <literal>-a</literal> to add a normal user and <literal>-A</literal> to add an admin user.
nb-NO: Vi bruker argumentet <literal>-a</literal> til å legge til en vanlig bruker og <literal>-A</literal> for å legge til en administratorbruker.

en: SIP Proxy Server
nb-NO: SIP-mellomtjener

en: A SIP proxy server manages the incoming and outgoing SIP connections between other organizations, SIP trunking providers, SIP PBXes such as Asterisk, SIP phones, SIP-based softphones and WebRTC applications.
nb-NO: En SIP-mellomtjener håndterer innkommende og utgående SIP-forbindelser mellom andre organisasjoner, SIP-kanalleverandører, SIP PBXer som Asterisk, SIP-telefoner, SIP-baserte PC-telefoner og WebRTC-applikasjoner.

en: <primary>SIP</primary><secondary>server</secondary>
nb-NO: <primary>SIP</primary><secondary>tjener</secondary>

en: <primary>SIP</primary><secondary>proxy</secondary>
nb-NO: <primary>SIP</primary><secondary>mellomtjener</secondary>

en: <primary>SIP</primary><secondary>trunk</secondary>
nb-NO: <primary>SIP</primary><secondary>tilkoblingspunkt</secondary>

en: It is strongly recommended to install and configure the SIP proxy before attempting a SIP PBX setup. The SIP proxy normalizes a lot of the traffic reaching the PBX and provides greater connectivity and resilience.
nb-NO: Det anbefales sterkt å installere og sette opp SIP-mellomtjeneren før du prøver et SIP PBX-oppsett. SIP-mellomtjeneren normaliserer mye av trafikken som når PBX, og gir større tilkoblingsmuligheter og elastisitet.

en: Install the SIP proxy
nb-NO: Å installere SIP-mellomtjener

en: Now we focus on the configuration file <filename>/etc/kamailio/kamailio.cfg</filename>. Falcot needs user authentication and persistent user location, so they add the following <literal>#!define</literal> directives at the top of that file:
nb-NO: Nå fokuserer vi på oppsettsfilen <filename>/etc/kamailio/kamailio.cfg</filename>. Falcot trenger brukerautentisering og en fast brukerplassering, slik at de legger til de følgende <literal>#!define</literal>-direktiver øverst i denne filen:

en: XMPP Server
nb-NO: XMPP-tjener

en: An XMPP server manages connectivity between local XMPP users and XMPP users in other domains on the public Internet.
nb-NO: En XMPP-tjener håndterer tilkobling mellom lokale XMPP-brukere og XMPP-brukere i andre domener på det offentlige Internettet.

en: <emphasis>VOCABULARY</emphasis> XMPP or Jabber?
nb-NO: <emphasis>ORDFORRÅD</emphasis> XMPP eller Jabber?

en: XMPP is sometimes referred to as Jabber. In fact, Jabber is a trademark and XMPP is the official name of the standard.
nb-NO: XMPP er noen ganger referert til som Jabber. Faktisk er Jabber et varemerke, og XMPP er det offisielle navnet på standarden.

en: Install the XMPP server
nb-NO: Å installere XMPP-tjener

en: Review the <filename>/etc/prosody/prosody.cfg.lua</filename> configuration file. The most important thing to do is insert JIDs of the users who are permitted to manage the server.
nb-NO: Gjennomgå <filename>/etc/prosody/prosody.cfg.lua</filename>-oppsettsfilen. Det viktigste å gjøre er å sette inn JISs til brukerne som har tillatelse til å håndtere tjeneren.

en: An individual configuration file is also needed for each domain. Copy the sample from <filename>/etc/prosody/conf.avail/example.com.cfg.lua</filename> and use it as a starting point. Here is <literal>falcot.com.cfg.lua</literal>:
nb-NO: Et individuell oppsettsfil er også nødvendig for hvert domene. Kopier eksemplet fra <filename>/etc/prosody/conf.avail/example.com.cfg.lua</filename>, og bruk det som et startpunkt. Her er <literal>falcot.com.cfg.lua</literal>:

en: To enable the domain, there must be a symlink from <filename>/etc/prosody/conf.d/</filename>. Create it that way:
nb-NO: For å aktivere domenet må det være en symlink fra <filename>/etc/prosody/conf.d/</filename>. Lag den på denne måten:

en: Restart the service to use the new configuration.
nb-NO: Start tjenesten på nytt for å bruke det nye oppsettet.

en: Managing the XMPP server
nb-NO: Å håndtere XMPP-tjeneren

en: See the <ulink url="https://prosody.im/doc/configure"> Prosody online documentation</ulink> for more details about how to customize the configuration.
nb-NO: Se <ulink url="https://prosody.im/doc/configure">Prosodi-dokumentasjon på nettet</ulink> for mer informasjon om hvordan du kan tilpasse oppsettet.

en: Running services on port 443
nb-NO: Å kjøre tjenester på port 443

en: Some administrators prefer to run all of their RTC services on port 443. This helps users to connect from remote locations such as hotels and airports where other ports may be blocked or Internet traffic is routed through HTTP proxy servers.
nb-NO: Noen administratorer foretrekker å kjøre alle sine RTC-tjenester på port 443. Dette hjelper brukere å koble til fra eksterne steder, som hoteller og flyplasser, der andre porter kan være blokkert, eller Internett-trafikken rutet gjennom HTTP-mellomtjenere.

en: To use this strategy, each service (SIP, XMPP and TURN) needs a different IP address. All the services can still be on the same host as Linux supports multiple IP addresses on a single host. The port number, 443, must be specified in the configuration files for each process and also in the DNS SRV records.
nb-NO: For å bruke denne strategien trenger hver tjeneste (SIP, XMPP og TURN) en ulik IP-adresse. Alle tjenestene kan fortsatt være på samme vert ettersom Linux støtter flere IP-adresser på en enkelt vert. Portnummeret 443 må spesifiseres i oppsettsfilene for hver prosess, og også i DNS SRV-registreringene.

en: Adding WebRTC
nb-NO: Å legge til WebRTC

en: Falcot wants to let customers make phone calls directly from the web site. The Falcot administrators also want to use WebRTC as part of their disaster recovery plan, so staff can use web browsers at home to log in to the company phone system and work normally in an emergency.
nb-NO: Falcot ønsker å la kundene ringe direkte fra nettstedet. Falcot-administratorene ønsker også å bruke WebRTC som en del av sin gjenopprettingsplan etter uhell, slik at ansatte kan bruke nettlesere hjemme til å logge inn på selskapets telefonsystem, og fungere normalt i en nødsituasjon.

en: <emphasis>IN PRACTICE</emphasis> Try WebRTC
nb-NO: <emphasis>I PRAKSIS</emphasis> Prøv WebRTC

en: <primary>WebRTC</primary><secondary>demonstration</secondary>
nb-NO: <primary>WebRTC</primary><secondary>demonstrasjon</secondary>

en: If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities. <ulink type="block" url="https://sip5060.net/test-calls" />
nb-NO: Hvis du ikke har prøvd WebRTC før, gir ulike nettsteder en tilkoblet demonstrasjon og testmuligheter. <ulink type="block" url="https://sip5060.net/test-calls" />

en: WebRTC is a rapidly evolving technology and it is essential to use packages from the <emphasis role="distribution">Testing</emphasis> distribution. Another option is to compile the software.
nb-NO: WebRTC er en teknologi i rask utvikling, og det er viktig å bruke pakker fra <emphasis role="distribution">Testing</emphasis>-distribusjonen. Et annet alternativ er å kompilere programvaren.

en: WebRTC uses a simple API to provide browsers and mobile applications with RTC, it is free software and it is being developed by Google. <ulink type="block" url="https://webrtc.org" />
nb-NO: WebRTC bruker en enkel API for å gi nettlesere og mobilapplikasjoner med RTC, det er gratis programvare og den blir utviklet av Google. <ulink type="block" url="https://webrtc.org" />

en: A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it: <ulink type="block" url="https://gitlab.freedesktop.org/gstreamer/gst-examples" />
nb-NO: En svært fleksibel tilnærming er å bruke GStreamers WebRTC-implementering. Det muliggjør pipeline-baserte multimedia applikasjoner, som gjør det mulig å utvikle interessante og svært effektive applikasjoner. Et godt utgangspunkt er følgende demo fra Centricular, hovedselskapet som utvikler det: <ulink type="block" url="https://gitlab.freedesktop.org/gstreamer/gst-examples" />

en: More advanced click-to-call web sites typically use server-side scripting to generate the <literal>config.js</literal> file dynamically. The <ulink url="https://www.drupal.org/project/drucall">DruCall</ulink> source code demonstrates how to do this with PHP.
nb-NO: Mer avanserte «klikk for å ringe»-nettsider bruker vanligvis tjenerside skripting for å generere <literal>config.js</literal>-filen dynamisk. <ulink url="https://www.drupal.org/project/drucall.org">DruCall</ulink>-kildekoden demonstrerer hvordan det kan gjøres med PHP.

en: This chapter sampled only a fraction of the available server software; however, most of the common network services were described. Now it is time for an even more technical chapter: we'll go into deeper detail for some concepts, describe massive deployments and virtualization.
nb-NO: Dette kapittelet har valgt ut bare en brøkdel av den tilgjengelige tjenerprogramvaren; men de fleste av de vanlige nett-tjenestene er beskrevet. Nå er tiden inne for et enda mer teknisk kapittel: Vi vil gå dypere inn i detaljene for noen begreper, beskrive massive utplasseringer og virtualisering.
