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

en: System boot
nb-NO: Systemoppstart

en: Initscripts
nb-NO: Initskript

en: Rights
nb-NO: Rettigheter

en: Permissions
nb-NO: Tillatelser

en: Supervision
nb-NO: Tilsyn

en: Backup
nb-NO: Sikkerhetskopiering

en: Hotplug
nb-NO: Driftskobling

en: Unix Services
nb-NO: Unix-tjenester

en: This chapter covers a number of basic services that are common to many Unix systems. All administrators should be familiar with them.
nb-NO: Dette kapitlet dekker en rekke grunnleggende tjenester felles for mange Unix-systemer. Alle administratorer bør være kjent med dem.

en: System Boot
nb-NO: Systemoppstart

en: <primary>booting</primary><secondary>the system</secondary>
nb-NO: <primary>oppstart</primary><secondary>systemet</secondary>

en: When you boot the computer, the many messages scrolling by on the console display many automatic initializations and configurations that are being executed. Sometimes you may wish to slightly alter how this stage works, which means that you need to understand it well. That is the purpose of this section.
nb-NO: Når du starter datamaskinen, vises de mange meldinger på konsollskjermen mange automatiske oppsett og igangsettinger. Noen ganger kan du ønske å endre litt på hvordan dette stadiet fungerer, noe som betyr at du må forstå det godt. Det er hensikten med dette avsnittet.

en: On systems with a BIOS, first, the BIOS takes control of the computer, initializes the controllers and hardware, detects the disks, and bridges everything together. Then it looks up the <emphasis>Master Boot Record</emphasis> (MBR) of the first disk in the boot order and loads the code stored there (first stage). This code then launches the second stage and finally executes the bootloader.
nb-NO: På systemer med BIOS, må BIOS først ta kontroll over datamaskinen, igangsette kontrollere og maskinvare, oppdage diskene, og knytte det hele sammen. Deretter sjekker den <emphasis>hovedoppstartssporet</emphasis> (MBR) for første disk i oppstartsrekkefølgen og laster inn koden som er lagret der (første trinn). Denne koden starter så andre trinn og kjører til slutt oppstartslasteren.

en: In contrast to the BIOS, UEFI is more sophisticated, it knows filesystems and can read the partition tables. The interface searches the system storage for a partition labeled with a specific globally unique identifier (<acronym>GUID</acronym>) that marks it as the <acronym>EFI System Partition</acronym> (<acronym>ESP</acronym>), where the bootloaders, boot managers, UEFI shell, etc., are located, and launches the desired bootloader. If Secure Boot is enabled, the boot process will verify authenticity of the EFI binaries there by signature (thus <emphasis role="pkg">grub-efi-<replaceable>arch</replaceable>-signed</emphasis> is required in this case). The UEFI specification also defines support for booting in legacy BIOS mode. This is called the <emphasis>Compatibility Support Module</emphasis> (<acronym>CSM</acronym>). If CSM is enabled, it will attempt to boot from a drive's MBR. However, many new systems do no longer support the CSM mode.
nb-NO: Til forskjell fra BIOS er UEFI mer sofistikert mtp. at det vet om filsystemer og kan lese partisjonstabeller. Grensesnittet søker i systemlagringen etter en partisjon merket med en globalt unik identifikator (<acronym>GUID</acronym>) som markerer den som <acronym>EFI-systemoartisjonen</acronym> (<acronym>ESP</acronym>), der oppstartslasteren, oppstartshåndterere, UEFI-skall, osv., er å finne, og starter ønsket oppstartsletter. Hvis Secure Boot er påskrudd vil prosessen bekrefte at EFI-binærfilene er sannferdige og samsvarer med sin signatur, altså er <emphasis role="pkg">grub-efi-<replaceable>arch</replaceable>-signed</emphasis> påkrevd for dette). UEFI-spesifikasjonen definerer også støtte for start i gammeldags BIOS-modus. Dette heter <emphasis>kompabilitetsstøttemodul</emphasis> (<acronym>CSM</acronym>). Hvis CSM er påskrudd vil den prøve å starte opp fra en enhets MBR. Dog er det mange nye systemer som ikke støtter CSM-modus.

en: The systemd init system
nb-NO: Systemd init system

en: The “real init” is currently provided by <emphasis role="pkg">systemd</emphasis> and this section documents this init system.
nb-NO: Den «ekte init-en» blir nå levert av <emphasis role="pkg">systemd</emphasis>, og dette avsnitter dokumenterer dette init-systemet.

en: <emphasis>CULTURE</emphasis> Before <command>systemd</command>
nb-NO: <emphasis>KULTUR</emphasis> før <command>systemd</command>

en: <command>systemd</command> is a relatively recent “init system”, and although it was already available, to a certain extent, in <emphasis role="distribution">Wheezy</emphasis>, it has only become the default in Debian <emphasis role="distribution">Jessie</emphasis>. Previous releases relied, by default, on the “System V init” (in the <emphasis role="pkg">sysv-rc</emphasis> package), a much more traditional system. We describe the System V init later on.
nb-NO: <command>systemd</command> er et relativt nytt «init-system», og selv om det allerede er tilgjengelig, til en viss grad, i <emphasis role="distribution">Wheezy</emphasis>, er det bare først blitt forvalg i Debian <emphasis role="distribution">Jessie</emphasis>. Tidligere versjoner bygger, som forvalg, på «System V-init» (i <emphasis role="pkg">sysv-rc</emphasis>-pakken), et mye mer tradisjonelt system. Vi beskriver System V-init senere.

en: <emphasis>ALTERNATIVE</emphasis> Other boot systems
nb-NO: <emphasis>ALTERNATIV</emphasis> Andre systemer for oppstart

en: <primary>boot systems</primary><seealso><command>init</command></seealso>
nb-NO: <primary>oppstartsystemer</primary><seealso><command>init</command></seealso>

en: The <command>upstart</command> system is still not perfectly tested on Debian. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent. This system, started by Ubuntu, was present in Debian <emphasis role="distribution">Jessie</emphasis>, but was not the default; it came, in fact, as a replacement for <emphasis role="pkg">sysvinit</emphasis>, and one of the tasks launched by <command>upstart</command> was to launch the scripts written for traditional systems, especially those from the <emphasis role="pkg">sysv-rc</emphasis> package.
nb-NO: <command>upstart</command>-systemet er fortsatt ikke testet helt ut på Debian. Det er hendelsesbasert: init-skript utføres ikke lenger i sekvensiell rekkefølge, men som respons til hendelser som for eksempel fullføring av et annet skript de er avhengige av. Dette systemet, startet av Ubuntu, var med i Debian <emphasis role="distribution">Jessie</emphasis>, men ikke forvalget. Det kom faktisk som en erstatning for <emphasis role="pkg">sysvinit</emphasis>, og en av oppgavene til <command>upstart</command> var å kjøre de prosedyrene som er skrevet for tradisjonelle systemer, spesielt de fra <emphasis role="pkg">sysv-rc</emphasis>-pakken.

en: Boot sequence of a computer running Linux with systemd
nb-NO: Oppstartssekvens med en datamaskin som kjører Linux med systemd

en: <emphasis>SPECIFIC CASE</emphasis> Booting from the network
nb-NO: <emphasis>KONKRET SAK</emphasis> Oppstart fra nettverket

en: Booting from the network can be used to launch the <command>debian-installer</command> or FAI (see <xref linkend="sect.installation-methods" />).
nb-NO: Oppstart fra nettverket kan bli brukt til å kjøre <command>debian-installer</command> eller FAI (se <xref linkend="sect.installation-methods" />).

en: <emphasis>BACK TO BASICS</emphasis> The process, a program instance
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Prosessen, et programeksempel

en: <primary>process</primary>
nb-NO: <primary>prosess</primary>

en: <emphasis>SECURITY</emphasis> Using a shell as <command>init</command> to gain root rights
nb-NO: <emphasis>SIKKERHET</emphasis> Bruk av skall som <command>init</command> for å få root-rettigheter

en: By convention, the first process that is booted is the <command>init</command> program (which is a symbolic link to <filename>/lib/systemd/systemd</filename> by default). However, it is possible to pass an <literal>init</literal> option to the kernel indicating a different program.
nb-NO: Tradisjonelt er den første prosessen som starter <command>init</command>-programmet (som normalt er en symbolsk lenke til <filename>/lib/systemd/systemd</filename>). Imidlertid er det mulig å sende et <literal>init</literal>-valg til kjernen for å indikere et annet program.

en: Any person who is able to access the computer can press the <keycap>Reset</keycap> button, and thus reboot it. Then, at the bootloader's prompt, it is possible to pass the <literal>init=/bin/sh</literal> option to the kernel to gain root access without knowing the administrator's password.
nb-NO: Alle som er i stand til å få tilgang til datamaskinen kan trykke på <keycap>Reset</keycap>-knappen og starte den på nytt. Så, på oppstartslasterens ledetekst, er det mulig å sende <literal>init=/bin/sh</literal>-valget til kjernen for å få rottilgang uten å kjenne administratorens passord.

en: To prevent this, you can protect the bootloader itself with a password. You might also think about protecting access to the BIOS (a password protection mechanism is almost always available), without which a malicious intruder could still boot the machine on a removable media containing its own Linux system, which they could then use to access data on the computer's hard drives.
nb-NO: For å unngå dette kan du beskytte oppstartslasteren med et passord. Du kan også tenke på å beskytte tilgang til BIOS (en mekanisme for passordbeskyttelse er nesten alltid tilgjengelig). Uten den kan en ondsinnet inntrenger fortsatt starte maskinen med et flyttbart medium som har sitt eget Linux-system, som de deretter kan bruke til å få tilgang til data på datamaskinens harddisker.

en: Systemd executes several processes, in charge of setting up the system: keyboard, drivers, filesystems, network, services. It does this while keeping a global view of the system as a whole, and the requirements of the components. Each component is described by a “unit file” (sometimes more); the general syntax is derived from the widely-used “*.ini files“ syntax, with <literal><replaceable>key</replaceable> = <replaceable>value</replaceable></literal> pairs grouped between <literal>[<replaceable>section</replaceable>]</literal> headers. Unit files are stored under <filename>/lib/systemd/system/</filename> and <filename>/etc/systemd/system/</filename>; they come in several flavors, but we will focus on “services” and “targets” here.
nb-NO: Systemd utfører flere prosesser, som har ansvaret for å sette opp systemet: tastatur, drivere, filsystemer, nettverk, tjenester. Den gjør dette mens du holder et overordnet oppsyn på systemet som helhet, og kravene til komponentene. Hver komponent er beskrevet av en «enhetsfil» («unit file») (noen ganger mer); den generelle syntaksen er avledet fra den ofte brukte «* INI-filer» syntaksen, med <literal><replaceable>nøkkel</replaceable> = <replaceable>verdi</replaceable></literal>-par gruppert mellom <literal>[<replaceable>seksjon</replaceable>]</literal>-topptekster. «Unit filer» er lagret i <filename>/lib/systemd/system/</filename>, og <filename>/etc/systemd/system/</filename>. De kommer i flere varianter, men her vil vi fokusere på «tjenester» og «mål».

en: <primary><command>systemd</command></primary><secondary><filename>.service</filename> file</secondary>
nb-NO: <primary><command>systemd</command></primary><secondary><filename>.service</filename>-fil</secondary>

en: <primary>service</primary><secondary><filename>ssh.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>ssh.service</filename></secondary>

en: The <literal>[Unit]</literal> section contains generic information about the service, like its description and manual page resources, as well as relations (dependency and order) to other services. The <literal>[Service]</literal> part contains the declarations related to the service execution (starting, stopping, killing, restarting), directories and configuration file(s) used. The last section, <literal>[Install]</literal>, again carries generic information into which targets to install the service and, in this case, the alias that can be used instead of the service name. As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed. The syntax of these files is fully described in several manual pages (e.g. <citerefentry><refentrytitle>systemd.service</refentrytitle> <manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd.unit</refentrytitle> <manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd.exec</refentrytitle> <manvolnum>5</manvolnum></citerefentry>, etc.).
nb-NO: <literal>[Unit]</literal>-delen inneholder generisk info om tjenesten, som f.eks. dens beskrivelse og manualsideressurser, og dens relasjoner (avhengigheter og rekkefølge) til andre tjenester. <literal>[Service]</literal>-delen inneholder deklarasjoner som har med tjenestekjøring å gjøre (starting, stopping, dreping, omstart), mapper og oppsettsfil(er) brukt. Siste del <literal>[Install]</literal>, har også generisk info om hvilke mål som skal installere tjenesten og i dette tilfellet alias som kan brukes istedenfor tjenestenavnet. Demonstrativt er det veldig lite kode der, kun deklarasjoner. Systemd tar hånd om visning av framdriftsrapporter, visning av prosesser, og faktisk også omstart av dem når det trengs. Syntaksen for disse filene er beskrevet i sin helhet fordelt på flere manualsider <citerefentry><refentrytitle>systemd.service</refentrytitle> <manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd.unit</refentrytitle> <manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd.exec</refentrytitle> <manvolnum>5</manvolnum></citerefentry>, osv.).

en: <primary><command>systemd</command></primary><secondary><filename>.target</filename> file</secondary>
nb-NO: <primary><command>systemd</command></primary><secondary><filename>.target</filename>-fil</secondary>

en: Since unit files are declarative rather than scripts or programs, they cannot be run directly, and they are only interpreted by systemd; several utilities therefore allow the administrator to interact with systemd and control the state of the system and of each component.
nb-NO: Siden enhetsfiler er deklarative heller enn skripter eller programmer, kan de ikke kjøres direkte, og de blir bare tolket av systemd. Flere verktøy tillater derfor administratoren å samhandle med systemd for å kontrollere tilstanden til systemet, og for hver komponent.

en: The first such utility is <command>systemctl</command>. When run without any arguments, it lists all the unit files known to systemd (except those that have been disabled), as well as their status. <command>systemctl status</command> gives a better view of the services, as well as the related processes. If given the name of a service (as in <command>systemctl status ntp.service</command>), it returns even more details, as well as the last few log lines related to the service (more on that later).
nb-NO: Det første slikt verktøy er <command>systemctl</command>. Kjørt uten argumenter, viser den alle enhetsfiler som er kjent for systemd (bortsett fra de som er blitt deaktivert), samt deres status. <command>systemctl status</command> gir en bedre oversikt over tjenestene, samt relaterte prosesser. Hvis navnet på en tjeneste er gitt (som i <command>systemctl status ntp.service</command>), returnerer den enda flere detaljer, så vel som de få siste logglinjer knyttet til denne tjenesten (mer om det senere).

en: Starting a service by hand is a simple matter of running <command>systemctl start <replaceable>servicename</replaceable>.service</command>. As one can guess, stopping the service is done with <command>systemctl stop <replaceable>servicename</replaceable>.service</command>; other subcommands include <command>reload</command> and <command>restart</command>.
nb-NO: Å starte en tjeneste for hånd er en enkel sak, kjør <command>systemctl start <replaceable>tjenestenavn</replaceable>.service</command>. Som man kan gjette seg til, å stoppe tjenesten gjøres med <command>systemctl stop <replaceable>tjenestenavn</replaceable>.service</command>. Andre underkommandoer inkluderer <command>reload</command> og <command>restart</command>.

en: To control whether a service is active (i.e. whether it will get started automatically on boot), use <command>systemctl enable <replaceable>servicename</replaceable>.service</command> (or <command>disable</command>). <command>is-enabled</command> allows checking the status of the service.
nb-NO: For å kontrollere om en tjeneste er aktiv (dvs. om den vil komme i gang automatisk ved oppstart), bruk <command>systemctl enable <replaceable>tjenestnavn</replaceable>.service</command> (eller <command>disable</command>). <command>is-enabled</command> åpner for å sjekke tjenestens status.

en: An interesting feature of systemd is that it includes a logging component named <command>journald</command>. It comes as a complement to more traditional logging systems such as <command>syslogd</command>, but it adds interesting features such as a formal link between a service and the messages it generates, and the ability to capture error messages generated by its initialization sequence. The messages can be displayed later on, with a little help from the <command>journalctl</command> command. Without any arguments, it simply spews all log messages that occurred since system boot; it will rarely be used in such a manner. Most of the time, it will be used with a service identifier:
nb-NO: Et interessant trekk ved systemd er at den inneholder en loggingskomponent som heter <command>journald</command>. Den kommer som et supplement til mer tradisjonelle loggingssystemer, for eksempel <command>syslogd</command>, men den legger til interessante funksjoner som en formell kobling mellom en tjeneste og meldingene den genererer, og evnen til å fange opp feilmeldinger generert fra sin initialiseringssekvens. Meldingene kan vises senere, med litt hjelp fra <command>journalctl</command>-kommandoen. Uten noen argumenter, avgir den bare alle loggmeldinger som har oppstått etter oppstart av systemet. Det vil sjelden bli brukt på den måten. Mesteparten av tiden vil den bli brukt med en tjenesteidentifikator:

en: Another useful command-line flag is <command>-f</command>, which instructs <command>journalctl</command> to keep displaying new messages as they are emitted (much in the manner of <command>tail -f <replaceable>file</replaceable></command>).
nb-NO: En annen nyttig kommandolinjemarkør er <command>-f</command>, som instruerer <command>journalctl</command> til å fortsette å vise nye meldinger etter hvert som de er sendt ut (mye på samme måte som <command>tail -f <replaceable>file</replaceable></command>).

en: If a service doesn't seem to be working as expected, the first step to solve the problem is to check that the service is actually running with <command>systemctl status</command>; if it is not, and the messages given by the first command are not enough to diagnose the problem, check the logs gathered by journald about that service. For instance, assume the SSH server doesn't work:
nb-NO: Hvis en tjeneste ikke ser ut til å virke som forventet, er første skritt for å løse problemet å kontrollere at tjenesten faktisk kjører, med <command>systemctl status</command>. Hvis den ikke kjører, og meldingene er gitt av den første kommandoen ikke er nok til å diagnostisere problemet, sjekk loggene samlet av journald om denne tjenesten. For eksempel, anta at SSH-tjeneren ikke virker:

en: After checking the status of the service (failed), we went on to check the logs; they indicate an error in the configuration file. After editing the configuration file and fixing the error, we restart the service, then verify that it is indeed running.
nb-NO: Etter å ha sjekket status på tjenesten (feilet), gikk vi videre til å sjekke loggene. De indikerer en feil i oppsettsfilen. Etter å ha endret på oppsettsfilen og fikset feilen, starter vi tjenesten, og kontroller så at den faktisk kjører.

en: <emphasis>GOING FURTHER</emphasis> Other types of unit files
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Andre typer enhetsfiler

en: We have only described the most basic of systemd's capabilities in this section. It offers many other interesting features; we will only list a few here:
nb-NO: Vi har bare beskrevet det mest grunnleggende av systemd sine muligheter i denne seksjonen. Den tilbyr mange andre interessante funksjoner, og vi vil bare liste noen her:

en: <primary><command>systemd</command></primary><secondary><filename>.socket</filename> file</secondary>
nb-NO: <primary><command>systemd</command></primary><secondary><filename>.socket</filename>-fil</secondary>

en: <primary><command>systemd</command></primary><secondary><filename>.timer</filename> file</secondary>
nb-NO: <primary><command>systemd</command></primary><secondary><filename>.timer</filename>-fil</secondary>

en: <primary><command>systemd</command></primary><secondary><filename>.network</filename> file</secondary>
nb-NO: <primary><command>systemd</command></primary><secondary><filename>.network</filename>-fil</secondary>

en: The System V init system
nb-NO: System V init system

en: Among these, you will find successively programs in charge of:
nb-NO: Blant disse finner du suksessivt programmer med ansvar for:

en: configuring the console's keyboard;
nb-NO: oppsettet av konsollets tastatur;

en: loading drivers: most of the kernel modules are loaded by the kernel itself as the hardware is detected; extra drivers are then loaded automatically when the corresponding modules are listed in <filename>/etc/modules</filename>;
nb-NO: laste drivere: de fleste av kjernemodulene er lastet av kjernen selv i takt med at maskinvaren blir oppdaget; ekstra drivere blir deretter lastet inn automatisk når de korresponderende modulene er oppført i <filename>/etc/modules</filename>;

en: checking the integrity of filesystems;
nb-NO: sjekke integriteten til filsystemene;

en: mounting local partitions;
nb-NO: montere lokale partisjoner;

en: configuring the network;
nb-NO: sette opp nettverket;

en: mounting network filesystems (NFS).
nb-NO: montere nettverk filsystemer (NFS).

en: <emphasis>BACK TO BASICS</emphasis> Kernel modules and options
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Kildemoduler og valgmuligheter

en: <primary>modules</primary><secondary>kernel modules</secondary>
nb-NO: <primary>moduler</primary><secondary>kjernemoduler</secondary>

en: <primary>kernel</primary><secondary>modules</secondary>
nb-NO: <primary>kjerne</primary><secondary>moduler</secondary>

en: <primary>kernel</primary><secondary>modules</secondary><tertiary>load</tertiary><seealso><command>modprobe</command></seealso>
nb-NO: <primary>kjerne</primary><secondary>moduler</secondary><tertiary>innlasting</tertiary><seealso><command>modprobe</command></seealso>

en: Having learned about systemd, services and targets can use the <filename>modprobe@<replaceable>module</replaceable>.service</filename> to load kernel modules they depend on.
nb-NO: Når du har lært om systemd, tjenester og mål kan du bruke <filename>modprobe@<replaceable>modul</replaceable>.service</filename> for å laste inn kjernemodulene de avhenger av.

en: <primary>service</primary><secondary><filename>modprobe@<replaceable>module</replaceable>.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>modprobe@<replaceable>modul</replaceable>.service</filename></secondary>

en: After this stage, <command>init</command> takes over and starts the programs enabled in the default runlevel (which is usually runlevel 2). It executes <command>/etc/init.d/rc 2</command>, a script that starts all services which are listed in <filename>/etc/rc2.d/</filename> and whose names start with the “S” letter. The two-figures number that follows had historically been used to define the order in which services had to be started, but nowadays the default boot system uses <command>insserv</command>, which schedules everything automatically based on the scripts' dependencies. Each boot script thus declares the conditions that must be met to start or stop the service (for example, if it must start before or after another service); <command>init</command> then launches them in the order that meets these conditions. The static numbering of scripts is therefore no longer taken into consideration (but they must always have a name beginning with “S” followed by two digits and the actual name of the script used for the dependencies). Generally, base services (such as logging with <command>rsyslog</command>, or port assignment with <command>portmap</command>) are started first, followed by standard services and the graphical interface (<command>gdm3</command>).
nb-NO: Etter dette trinnet tar <command>init</command> over, og starter programmene aktivert i standard kjørenivå (som vanligvis er driftsnivå 2). Den utfører <command>/etc/init.d/rc 2</command>, et skript som starter alle tjenestene som er oppført i <filename>/etc/rc2.d/</filename>, og der navnet begynner med bokstaven «S». Det tosifrede nummer som følger, har historisk blitt brukt til å definere i hvilken rekkefølge tjenestene måtte startes, men i dag brukes det standard oppstartssystemet <command>insserv</command>, som berammer alt automatisk basert på skriptenes avhengigheter. Hvert oppstartsskript melder om betingelsene som må være oppfylt for å starte eller stoppe tjenesten (for eksempel hvis det må starte før eller etter en annen tjeneste); så starter <command>init</command> dem i den rekkefølgen som oppfyller disse betingelsene. Skriptenes statiske nummerering tas derfor ikke lenger i betraktning (men de må alltid ha et navn som begynner med «S» etterfulgt av to sifre, og selve navnet på skriptet som brukes for avhengighetene. Vanligvis startes basistjenester (for eksempel logger med <command>rsyslog</command>, eller tildeling av port med <command>portmap</command>) først, fulgt av standardtjenestene og det grafiske brukergrensesnittet (<command>gdm3</command>).

en: This dependency-based boot system makes it possible to automate re-numbering, which could be rather tedious if it had to be done manually, and it limits the risks of human error, since scheduling is conducted according to the parameters that are indicated. Another benefit is that services can be started in parallel when they are independent from one another, which can accelerate the boot process.
nb-NO: Dette avhengighetsbaserte oppstartssystemet gjør det mulig å automatisere renummerering, som kan være ganske kjedelig hvis det må gjøres manuelt. Det begrenser risikoen for menneskelige feil, ettersom tidsrekkefølgen blir gjennomført i henhold til de parameterne som er angitt. En annen fordel er at tjenester kan startes parallelt når de er uavhengige av hverandre, noe som kan akselerere oppstartsprosessen.

en: <primary>runlevel</primary>
nb-NO: <primary>driftsnivå (runlevel)</primary>

en: <primary>level, runlevel</primary>
nb-NO: <primary>nivå, driftsnivå (runlevel)</primary>

en: <command>init</command> distinguishes several runlevels, so it can switch from one to another with the <command>telinit <replaceable>new-level</replaceable></command> command. Immediately, <command>init</command> executes <command>/etc/init.d/rc</command> again with the new runlevel. This script will then start the missing services and stop those that are no longer desired. To do this, it refers to the content of the <filename>/etc/rc<replaceable>X</replaceable>.d</filename> (where <replaceable>X</replaceable> represents the new runlevel). Scripts starting with “S” (as in “Start”) are services to be started; those starting with “K” (as in “Kill”) are the services to be stopped. The script does not start any service that was already active in the previous runlevel.
nb-NO: <command>init</command> skiller mellom ulike kjørenivåer, så det kan bytte fra ett til et annet med <command>telinit <replaceable>new-level</replaceable></command>-kommandoen. Umiddelbart vil <command>init</command> kjøre <command>/etc/init.d/rc</command> igjen med det nye kjørenivået. Dette skriptet vil da starte de manglende tjenestene, og stoppe de som ikke lenger er ønsket. For å gjøre dette viser det til innholdet i <filename>/etc/rc<replaceable>X</replaceable>.d</filename> (der <replaceable>X</replaceable> representerer det nye kjørenivået). Skript som begynner med «S» (som i «Start») er tjenester som skal i gang; de som starter med «K» (som i «Kill») er de tjenestene som skal stoppes. Skriptet starter ikke noen tjenester som allerede var aktive med det forrige driftsnivået.

en: <primary>System V init</primary><secondary>runlevels</secondary>
nb-NO: <primary>System V init</primary><secondary>kjørenivå</secondary>

en: By default, System V init in Debian uses four different runlevels:
nb-NO: Som standard bruker System V init i Debian fire forskjellige driftsnivåer:

en: Level 0 is only used temporarily, while the computer is powering down. As such, it only contains many “K” scripts.
nb-NO: Nivå 0 brukes bare midlertidig, mens maskinen slår seg av. Dermed inneholder den bare mange «K»-skripter.

en: Level 1, also known as single-user mode, corresponds to the system in degraded mode; it includes only basic services, and is intended for maintenance operations where interactions with ordinary users are not desired.
nb-NO: Nivå 1, også kjent som enkeltbrukermodus, tilsvarer systemet i nedgradert modus; det inneholder bare basistjenester, og er beregnet for vedlikeholdsoperasjoner hvor samhandling med vanlige brukere ikke er ønsket.

en: Level 2 is the level for normal operation, which includes networking services, a graphical interface, user logins, etc.
nb-NO: Nivå 2 er nivået for normal drift, som omfatter nettverkstjenester, et grafisk grensesnitt, brukerpålogging, etc.

en: Level 6 is similar to level 0, except that it is used during the shutdown phase that precedes a reboot.
nb-NO: Nivå 6 er lik nivå 0, bortsett fra at det brukes under nedkoblingsfasen før en omstart.

en: Other levels exist, especially 3 to 5. By default they are configured to operate the same way as level 2, but the administrator can modify them (by adding or deleting scripts in the corresponding <filename>/etc/rc<replaceable>X</replaceable>.d</filename> directories) to adapt them to particular needs.
nb-NO: Andre nivåer finnes, spesielt 3 til 5. Som standard er de satt opp til å operere på samme måte som nivå 2, men administratoren kan endre dem (ved å legge til eller slette skript i de tilsvarende <filename>/etc/rc<replaceable>X</replaceable>.d</filename> kataloger) for å tilpasse dem til spesielle behov.

en: Boot sequence of a computer running Linux with System V init
nb-NO: Oppstartssekvens for en datamaskin som kjører Linux med System V init

en: <primary>initialization script</primary>
nb-NO: <primary>initialiseringsskript</primary>

en: <emphasis>DEBIAN POLICY</emphasis> Restarting services
nb-NO: <emphasis>DEBIAN-RETNINGSLINJER</emphasis> Omstart av tjenester

en: <primary>service</primary><secondary>restart</secondary>
nb-NO: <primary>tjenesten</primary><secondary>restart</secondary>

en: <primary>restarting services</primary>
nb-NO: <primary>omstart av tjenester</primary>

en: The maintainer scripts for Debian packages will sometimes restart certain services to ensure their availability or get them to take certain options into account. The command that controls a service — <command>service <replaceable>service</replaceable> <replaceable>operation</replaceable></command> — doesn't take runlevel into consideration, assumes (wrongly) that the service is currently being used, and may thus initiate incorrect operations (starting a service that was deliberately stopped, or stopping a service that is already stopped, etc.). Debian therefore introduced the <command>invoke-rc.d</command> program: this program must be used by maintainer scripts to run services initialization scripts and it will only execute the necessary commands. Note that, contrary to common usage, the <filename>.d</filename> suffix is used here in a program name, and not in a directory.
nb-NO: Vedlikeholdsskripter for Debian-pakker vil noen ganger gi visse tjenester en omstart for å sikre at de er tilgjengelige, eller få dem til å ta hensyn til visse valgmuligheter. Kommandoen som styrer en tjeneste - <command>tjeneste <replaceable>tjeneste</replaceable> <replaceable>operasjon</replaceable></command> - tar ikke driftsnivå i betraktning, forutsetter (feilaktig) at tjenesten brukes for øyeblikket, og kan dermed iverksette uriktige operasjoner (starter en tjeneste som bevisst var bevisst, eller stoppe en tjeneste som allerede er stanset, etc.). Debian introduserte derfor <command>invoke-rc.d</command>-programmet: Dette programmet må benyttes av vedlikeholdsskripter til å kjøre skripter for å ta initiativet til tjenester, og det vil bare utføre de nødvendige kommandoer. Legg merke til at, i motsetning til vanlig bruk, er <filename>.d</filename>-suffikset her brukt i et programnavn, og ikke i en katalog.

en: Finally, <command>init</command> starts control programs for various virtual consoles (<command>getty</command>). It displays a prompt, waiting for a username, then executes <command>login <replaceable>user</replaceable></command> to initiate a session.
nb-NO: Til slutt, <command>init</command> starter kontrollprogrammer for ulike virtuelle konsoller (<command>getty</command>). Den viser en ledetekst, venter på et brukernavn, og så kjører <command>login <replaceable>bruker</replaceable></command> for å starte en økt.

en: <primary>service</primary><secondary><filename>getty@.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>getty@.service</filename></secondary>

en: <emphasis>VOCABULARY</emphasis> Console and terminal
nb-NO: <emphasis>ORDFORRÅD</emphasis> Konsoll og terminal

en: The first computers were usually separated into several, very large parts: the storage enclosure and the central processing unit were separate from the peripheral devices used by the operators to control them. These were part of a separate furniture, the “console”. This term was retained, but its meaning has changed. It has become more or less synonymous with “terminal”, being a keyboard and a screen.
nb-NO: De første datamaskinene besto vanligvis av flere, svært store deler: Lagringskabinett og den sentrale prosessenheten var atskilt fra eksterne enheter som ble brukt av operatørene til å kontrollere maskinene. Dette var deler i et eget møbel, «konsollet». Dette begrepet ble beholdt, men betydningen har endret seg. Det har blitt mer eller mindre synonymt med «terminal», som er et tastatur og en skjerm.

en: With the development of computers, operating systems have offered several virtual consoles to allow for several independent sessions at the same time, even if there is only one keyboard and screen. Most GNU/Linux systems offer six virtual consoles (in text mode), accessible by typing the key combinations <keycombo action="simul"> <keycap>Control</keycap> <keycap>Alt</keycap> <keycap>F1</keycap> </keycombo> through <keycombo action="simul"> <keycap>Control</keycap> <keycap>Alt</keycap> <keycap>F6</keycap> </keycombo>.
nb-NO: Med utviklingen av datamaskiner, tilbyr operativsystemer flere virtuelle konsoller for å muliggjøre flere uavhengige økter på samme tid, selv om det er bare ett tastatur og en skjerm. De fleste GNU/Linux-systemer tilbyr seks virtuelle konsoller (i tekstmodus), som er tilgjengelige ved å skrive inn tastekombinasjonene <keycombo action="simul"> <keycap>Control</keycap> <keycap>Alt</keycap> <keycap>F1</keycap> </keycombo> til <keycombo action="simul"> <keycap>Control</keycap> <keycap>Alt</keycap> <keycap>F6</keycap> </keycombo>.

en: Remote Login
nb-NO: Ekstern innlogging

en: It is essential for an administrator to be able to connect to a computer remotely. Servers, confined in their own room, are rarely equipped with permanent keyboards and monitors — but they are connected to the network.
nb-NO: Det er viktig for en administrator å kunne koble seg til en datamaskin utenfra. Tjenere, innesperret i sitt eget rom, er sjelden utstyrt med permanente tastaturer og skjermer - men de er koblet til nettverket.

en: <emphasis>BACK TO BASICS</emphasis> Client, server
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Klient, tjener

en: <primary>client</primary><secondary>client/server architecture</secondary>
nb-NO: <primary>klient</primary><secondary>klient-/tjener -arkitektur</secondary>

en: <primary>server</primary><secondary>client/server architecture</secondary>
nb-NO: <primary>tjener</primary><secondary>klient-/tjener -arkitektur</secondary>

en: A system where several processes communicate with each other is often described with the “client/server” metaphor. The server is the program that takes requests coming from a client and executes them. It is the client that controls operations, the server doesn't take any initiative of its own.
nb-NO: Et system hvor flere prosesser kommuniserer med hverandre, blir ofte beskrevet med «klient/tjener» metaforer. Tjeneren er programmet som tar forespørsler som kommer fra en klient, og utfører dem. Det er klienten som styrer operasjonene, tjeneren tar ikke noen egne initiativ.

en: <primary>login</primary><secondary>remote login</secondary>
nb-NO: <primary>logg inn</primary><secondary>logge inn eksternt </secondary>

en: <primary>remote login</primary>
nb-NO: <primary>logge inn eksternt</primary>

en: Secure Remote Login: SSH
nb-NO: Sikker ekstern innlogging: SSH

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

en: The <emphasis>SSH</emphasis> (Secure SHell) protocol was designed with security and reliability in mind. Connections using SSH are secure: the partner is authenticated and all data exchanges are encrypted.
nb-NO: <emphasis>SSH</emphasis> (Secure SHell)-protokollen ble utformet med tanke på sikkerhet og pålitelighet. Tilkoblinger som bruker SSH er sikre: Partneren er godkjent, og all datautveksling er kryptert.

en: <emphasis>CULTURE</emphasis> Telnet and RSH are obsolete
nb-NO: <emphasis>KULTUR</emphasis> Telnet og RSH er foreldet

en: Before SSH, <emphasis>Telnet</emphasis> and <emphasis>RSH</emphasis> were the main tools used to login remotely. They are now largely obsolete and should no longer be used even if Debian still provides them.
nb-NO: Før SSH var <emphasis>Telnet</emphasis> og <emphasis>RSH</emphasis> de viktigste verktøyene for ekstern innlogging. Nå er de i stor grad foreldet, og skal ikke lenger brukes selv om Debian fortsatt har dem med.

en: <emphasis>VOCABULARY</emphasis> Authentication, encryption
nb-NO: <emphasis>ORDFORRÅD</emphasis> Autentisering, kryptering

en: Authentication and encryption are often mentioned together, both because they are frequently used together, and because they are usually implemented with similar mathematical concepts.
nb-NO: Autentisering og kryptering er ofte nevnt sammen, både fordi de ofte er brukt sammen, og fordi de vanligvis gjennomføres med matematiske begreper som ligner hverandre.

en: SSH also offers two file transfer services. <command>scp</command> is a command line tool that can be used like <command>cp</command>, except that any path to another machine is prefixed with the machine's name, followed by a colon.
nb-NO: SSH tilbyr også to filoverføringstjenester. <command>scp</command> er et kommandolinjeverktøy som kan brukes som <command>cp</command>, bortsett fra at hvilken som helst sti til en annen maskin har et prefiks med maskinens navn, etterfulgt av et kolon.

en: <computeroutput>$ </computeroutput><userinput>scp file machine:/tmp/</userinput>
nb-NO: <computeroutput>$ </computeroutput><userinput>scp fil maskin:/tmp/</userinput>

en: <command>sftp</command> is an interactive command, similar to <command>ftp</command>. In a single session, <command>sftp</command> can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.).
nb-NO: <command>sftp</command> er en interaktiv kommando, som svarer til <command>ftp</command>. I en enkelt økt kan <command>sftp</command> overføre flere filer, og med den er det mulig å manipulere eksterne filer (slette, endre navn, endre tillatelser, etc.).

en: Debian uses OpenSSH, a free version of SSH maintained by the <command>OpenBSD</command> project (a free operating system based on the BSD kernel, focused on security) and fork of the original SSH software developed by the SSH Communications Security Corp company, of Finland. This company initially developed SSH as free software, but eventually decided to continue its development under a proprietary license. The OpenBSD project then created OpenSSH to maintain a free version of SSH.
nb-NO: Debian bruker OpenSSH, som er en fri versjon av SSH, som vedlikeholdes av <command>OpenBSD</command>-prosjektet (et fritt operativsystem basert på BSD-kjernen, med fokus på sikkerhet), og er en forgrening av den opprinnelige SSH-programvaren utviklet av selskapet SSH Communications Security Corp i Finland. Dette selskapet utviklet opprinnelig SSH som fri programvare, men som til slutt bestemte seg for å fortsette utviklingen under en proprietær lisens. OpenBSD-prosjektet opprettet deretter OpenSSH for å opprettholde en fri versjon av SSH.

en: <emphasis>BACK TO BASICS</emphasis> <foreignphrase>Fork</foreignphrase>
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> <foreignphrase>forgrening</foreignphrase>

en: <primary>fork</primary>
nb-NO: <primary>forgrening</primary>

en: A “fork”, in the software field, means a new project that starts as a clone of an existing project, and that will compete with it. From there on, both software will usually quickly diverge in terms of new developments. A fork is often the result of disagreements within the development team.
nb-NO: På programvarefeltet betyr en «forgrening et nytt prosjekt som starter som en klone av et eksisterende prosjekt, og som vil konkurrere med det. Fra da av vil begge programvarer raskt avvike fra hverandre i nyutvikling. En forgrening er ofte et resultat av uenighet innenfor utviklingsteamet.

en: The option to fork a project is a direct result of the very nature of free software; a fork is a healthy event when it enables the continuation of a project as free software (for example in case of license changes). A fork arising from technical or personal disagreements is often a waste of human resources; another resolution would be preferable. Mergers of two projects that previously went through a prior fork are not unheard of.
nb-NO: Alternativet til å «forgrene» et prosjekt, er et direkte resultat av selve naturen til fri programvare; en forgrening er en sunn hendelse når det muliggjør en videreføring av et prosjekt som fri programvare (for eksempel i tilfelle av lisensendringer). En forgrening, som følge av tekniske eller personlige uoverensstemmelser, er ofte en sløsing med menneskelige ressurser; en annen løsning ville være å foretrekke. Det har skjedd at to prosjekter som tidligere har delt seg, senere har slått seg sammen igjen.

en: Key-Based Authentication
nb-NO: Nøkkel-basert autentisering

en: <primary>SSH</primary><secondary>key creation</secondary>
nb-NO: <primary>SSH</primary><secondary>nøkkeloppretting</secondary>

en: Each time someone logs in over SSH, the remote server asks for a password to authenticate the user. This can be problematic if you want to automate a connection, or if you use a tool that requires frequent connections over SSH. This is why SSH offers a key-based authentication system.
nb-NO: Hver gang noen logger inn over SSH, spør en ekstern tjener om et passord for å autentisere brukeren. Dette kan være problematisk hvis du ønsker å automatisere en tilkobling, eller hvis du bruker et verktøy som krever hyppige forbindelser over SSH. Dette er grunnen til at SSH tilbyr et nøkkelbasert autentiseringssystem.

en: The user generates a key pair on the client machine with <command>ssh-keygen -t rsa</command>; the so generated public key is stored in <filename>~/.ssh/id_rsa.pub</filename>, while the corresponding private key is stored in <filename>~/.ssh/id_rsa</filename>. The user can then use <command>ssh-copy-id <replaceable>server</replaceable></command> to add their public key to the <filename>~/.ssh/authorized_keys</filename> file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.
nb-NO: Brukeren genererer et nøkkelpar på klientmaskinen med <command>ssh-keygen -t rsa</command>; den deretter genererte offentlige nøkkelen lagres i <filename>~/.ssh/id_rsa.pub</filename>, mens den private motsatsen lagres i <filename>~/.ssh/id_rsa</filename>. Brukeren kan deretter bruke <command>ssh-copy-id <replaceable>tjener</replaceable></command> for å legge til sin offentlige nøkkel til i <filename>~/.ssh/authorized_keys</filename>-filen på tjeneren, eller, (hvis SSH-tilgang ikke har blitt påskrudd enda) spørre administrator om å legge til brukerens nøkkel manuelt.

en: <primary>SSH</primary><secondary>passphrase cache</secondary>
nb-NO: <primary>SSH</primary><secondary>passordfrase-mellomlager</secondary>

en: <primary>SSH</primary><secondary>passwordless</secondary>
nb-NO: <primary>SSH</primary><secondary>passordløst</secondary>

en: <emphasis>SECURITY</emphasis> Protection of the private key
nb-NO: <emphasis>SIKKERHET</emphasis> Beskyttelse av den private nøkkelen

en: <primary>SSH</primary><secondary>private key</secondary>
nb-NO: <primary>SSH</primary><secondary>privat nøkkel</secondary>

en: Whoever has the private key can login on the account thus configured. This is why access to the private key is protected by a “passphrase”. Someone who acquires a copy of a private key file (for example, <filename>~/.ssh/id_rsa</filename>) still has to know this phrase in order to be able to use it. This additional protection is not, however, impregnable, and if you think that this file has been compromised, it is best to disable that key on the computers in which it has been installed (by removing it from the <filename>authorized_keys</filename> files) and replacing it with a newly generated key.
nb-NO: Den som har den private nøkkelen, kan logge seg på den kontoen som er satt opp for det. Dette er grunnen til at tilgang til den private nøkkelen er beskyttet av en «adgangsfrase» («passphrase»). Noen som får en kopi av en privat nøkkelfil (for eksempel <filename>~/.ssh/id_rsa</filename>), må fremdeles kjenne denne frasen for å kunne bruke den. Denne ekstra beskyttelse er imidlertid ikke uangripelig, og hvis du tror at denne filen har blitt kompromittert, er det best å deaktivere den nøkkelen på datamaskinene der den har blitt installert (ved å fjerne den fra <filename>authorized_keys</filename> filer), og erstatte den med en nylig generert nøkkel.

en: <emphasis>CULTURE</emphasis> OpenSSL flaw in Debian <emphasis role="distribution">Etch</emphasis>
nb-NO: <emphasis>KULTUR</emphasis> OpenSSL feil i Debian <emphasis role="distribution">Etch</emphasis>

en: The OpenSSL library, as initially provided in Debian <emphasis role="distribution">Etch</emphasis>, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like <command>valgrind</command>. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness. <ulink type="block" url="https://www.debian.org/security/2008/dsa-1571" />
nb-NO: OpenSSL-biblioteket, som i utgangspunktet er tilgjengelig i Debian <emphasis role="distribution">Etch</emphasis>, hadde et alvorlig problem i sin generator for tilfeldige tall (RNG). Faktisk hadde Debians vedlikeholder gjort en endring slik at programmer som bruker den, ikke lenger ville generere advarsler når den ble analysert av et testverktøy for minnet som <command>valgrind</command>. Dessverre, denne endringen betydde også at RNG-en bare anvender en entropi-kilde som korresponderer med prosessantallet (PID), der 32 000 mulige verdier ikke gir tilstrekkelig tilfeldighet. <ulink type="block" url="https://www.debian.org/security/2008/dsa-1571" />

en: Specifically, whenever OpenSSL was used to generate a key, it always produced a key within a known set of hundreds of thousands of keys (32,000 multiplied by a small number of key lengths). This affected SSH keys, SSL keys, and X.509 certificates used by numerous applications, such as OpenVPN. A cracker had only to try all of the keys to gain unauthorized access. To reduce the impact of the problem, the SSH daemon was modified to refuse problematic keys that are listed in the <emphasis role="pkg">openssh-blacklist</emphasis> and <emphasis role="pkg">openssh-blacklist-extra</emphasis> packages. Additionally, the <command>ssh-vulnkey</command> command allows identification of possibly compromised keys in the system.
nb-NO: Spesielt når OpenSSL ble brukt til å generere en nøkkel, produserte den alltid en nøkkel i løpet av et visst sett av hundretusener av nøkler (32 000 multiplisert med et lite antall nøkkellengder). Dette påvirket SSH-nøkler, SSL-nøkler og X.509-sertifikater som brukes av mange programmer, som OpenVPN. En inntrenger trengte bare å prøve alle nøklene for å få uautorisert tilgang. For å redusere virkningen av problemet ble SSH-bakgrunnsprosessen modifisert til å nekte problematiske nøkler som er oppført i <emphasis role="pkg">openssh-blacklist</emphasis>- og <emphasis role="pkg">openssh-blacklist-extra</emphasis>-pakkene. I tillegg tillater <command>ssh-vulnkey</command>-kommandoen identifisering av mulige kompromitterte nøkler i systemet.

en: A more thorough analysis of this incident brings to light that it is the result of multiple (small) problems, both within the OpenSSL project and with the Debian package maintainer. A widely used library like OpenSSL should — without modifications — not generate warnings when tested by <command>valgrind</command>. Furthermore, the code (especially the parts as sensitive as the RNG) should be better commented to prevent such errors. On Debian's side, the maintainer wanted to validate the modifications with the OpenSSL developers, but simply explained the modifications without providing the corresponding patch to review and failed to mention his role within Debian. Finally, the maintenance choices were sub-optimal: the changes made to the original code were not clearly documented; all the modifications were effectively stored in a Subversion repository, but they ended up all lumped into one single patch during creation of the source package.
nb-NO: En grundigere analyse av denne hendelsen bringer frem i lyset at det er et resultat av flere (små) problemer, både i OpenSSL-prosjektet og med Debian-pakkevedlikeholderen. Et mye brukt bibliotek som OpenSSL skal - uten endringer - ikke generere advarsler under testing av <command>valgrind</command>. Videre bør koden (spesielt de delene som er så følsomme som RNG) bli bedre kommentert for å forhindre slike feil. På Debians side, ønsket vedlikeholderen å validere modifikasjonene med OpenSSLs utviklere, men forklarte ganske enkelt endringene, uten å legge ut den korresponderende programfiksen til gjennomgang, og unnlot å nevne sin rolle i Debian. Endelig, vedlikeholdsvalgene var sub-optimale: Endringene i den opprinnelige koden ble ikke klart dokumentert; alle modifikasjoner ble effektivt lagret i en Subversjon kildebrønn, men de endte opp med alt samlet i en enkelt programfiks under oppretting av kildepakken.

en: It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed. <ulink type="block" url="https://sources.debian.org" />
nb-NO: Det er vanskelig under slike forhold å finne de korrigerende tiltak for å hindre gjentakelse av slike hendelser. Denne leksen ga her den lærdommen at alle divergenser Debian introduserer i oppstrøms programvare, må begrunnes, dokumenteres, sendes til oppstrømsprosjektetet når det er mulig, og publiseres vidt. Det er ut fra dette perspektivet at det nye kildepakkeformatet («3.0 (quilt)») og webtjenesten for Debian-kilder ble utviklet. <ulink type="block" url="https://sources.debian.netorg" />

en: <primary>SSH</primary><secondary>signed key</secondary>
nb-NO: <primary>SSH</primary><secondary>signert nøkkel</secondary>

en: Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the <filename>known_hosts</filename> file (even system wide via <filename>/etc/ssh/known_hosts</filename>).
nb-NO: Vice versa kan klientene også settes opp til å stole på vertsnøkkelen signert av samme myndighet, noe som gjør det enklere å håndtere <filename>known_hosts</filename>-filen (selv for hele systemet via <filename>/etc/ssh/known_hosts</filename>).

en: Both, public key and certificate authentication, can be used alongside each other.
nb-NO: Både identitetsbekreftelse med offentlig nøkkel og sertifikat kan brukes samtidig.

en: Using Remote X11 Applications
nb-NO: Ved hjelp av Remote X11-programmer

en: The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying <literal>X11Forwarding yes</literal> in the server configuration file (<filename>/etc/ssh/sshd_config</filename>). Finally, the user must also request it by adding the <literal>-X</literal> option to the <command>ssh</command> command-line.
nb-NO: SSH-protokollen tillater videresending av grafiske data («X11»-økt, fra navnet på det mest utbredte grafiske systemet i Unix); tjeneren holder da en egen kanal for disse dataene. Spesielt kan et grafisk program, kjørt eksternt, vises på X.org-tjeneren til den lokale skjermen, og hele økten (inndata og visning) vil være sikker. Ettersom denne funksjonen tillater at eksterne programmer forstyrrer det lokale systemet, er det deaktivert som standard. Du kan aktivere det ved å angi <literal>X11Forwarding yes</literal> i tjeneroppsettsfilen (<filename>/etc/ssh/sshd_config</filename>). Avslutningsvis må brukeren også be om det ved å legge <literal>-X</literal>-valget til <command>ssh</command>-kommandolinjen.

en: When a user connects via SSH and starts a remote X11 session, a so-called <emphasis>magic cookie</emphasis> is created and stored in the <filename>.Xauthority</filename> file in the user's home directory that initiated the connection. This cookie is used by <command>xauth</command> to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using <command>su</command> or <command>sudo</command>, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via <command>xauth</command>) to allow another user to start graphical programs as well during the X session.
nb-NO: Når en bruker kobler til via SSH og starter en X11-økt annensteds fra, vil en såkalt <emphasis>magisk kake</emphasis> opprettes og lagres i <filename>.Xauthority</filename>-fil i brukermappen til den som igangsatte tilkoblingen. Denne kaken brukes av <command>xauth</command> til å identitetsbekrefte brukeren i løpet av X-økten. Hvis brukeren later som om den er noen andre på systemet, f.eks. ved bruk av <command>su</command> eller <command>sudo</command>, blir kaken ikke kopiert automatisk til målbrukeren, og X-tjeneren vil nekte å starte grafiske programmer i målbrukerens kontekst. Du vil måtte kopiere den magiske kaken inn i målbrukerens hjemmemappe (før du eksporterer og reimporterer kaken via <command>xauth</command>) for å tillate en annen bruker å også starte grafiske programmer i løpet av X-økten.

en: Creating Encrypted Tunnels with Port Forwarding
nb-NO: Å lage krypterte tunneler med portvideresending (Port Forwarding)

en: <primary>port forwarding</primary>
nb-NO: <primary>port-videresending (port forwarding)</primary>

en: <primary>SSH</primary><secondary>port forwarding</secondary>
nb-NO: <primary>SSH</primary><secondary>portvideresending</secondary>

en: <primary>SSH</primary><secondary>tunnel</secondary>
nb-NO: <primary>SSH</primary><secondary>tunnell</secondary>

en: Its <literal>-R</literal> and <literal>-L</literal> options allow <command>ssh</command> to create “encrypted tunnels” between two machines, securely forwarding a local TCP port (see sidebar <xref linkend="sidebar.tcp-udp" />) to a remote machine or vice versa.
nb-NO: Dets <literal>-R</literal> og <literal>-L</literal>-valg tillater <command>ssh</command> å lage «krypterte tunneler» mellom to maskiner, sikker videresending til en lokal TCP-port (se sidestolpe <xref linkend="sidebar.tcp-udp" />) til en ekstern maskin og omvendt.

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

en: <primary>tunnel</primary><secondary>SSH</secondary><seealso>VPN</seealso>
nb-NO: <primary>tunnell</primary><secondary>SSH</secondary><seealso>VPN</seealso>

en: <primary>SSH</primary><secondary>tunnel</secondary><seealso>VPN</seealso>
nb-NO: <primary>SSH</primary><secondary>tunnell</secondary><seealso>VPN</seealso>

en: The Internet, and most LANs that are connected to it, operate in packet mode and not in connected mode, meaning that a packet issued from one computer to another is going to be stopped at several intermediary routers to find its way to its destination. You can still simulate a connected operation where the stream is encapsulated in normal IP packets. These packets follow their usual route, but the stream is reconstructed unchanged at the destination. We call this a “tunnel”, analogous to a road tunnel in which vehicles drive directly from the entrance (input) to the exit (output) without encountering any intersections, as opposed to a path on the surface that would involve intersections and changing direction.
nb-NO: Internettet, og de fleste lokalnett som er koblet til det, opererer i pakke-modus, og ikke i tilkoblet modus. Dette betyr at en pakke utstedt fra en datamaskin til en annen, kommer til å bli oppholdt på flere mellomliggende rutere for å finne veien til sin destinasjon. Du kan fortsatt simulere en tilkoblet operasjon der strømmen er innkapslet i normale IP-pakker. Disse pakkene følger sin vanlige rute, men strømmen blir rekonstruert uendret på bestemmelsesstedet. Vi kaller dette en «tunnel», tilsvarende en veitunnel der biler kjører direkte fra inngangen (inndata) til utgangen (utdata) uten å møte noen kryss, i motsetning til en bane på overflaten, som ville innebære kryss og skiftende retninger.

en: You can use this opportunity to add encryption to the tunnel: the stream that flows through it is then unrecognizable from the outside, but it is returned in decrypted form at the exit of the tunnel.
nb-NO: Du kan bruke denne muligheten til å legge kryptering til tunnelen: Strømmen som flommer igjennom er da ugjenkjennelig fra utsiden, men den blir levert dekryptert ved utgangen av tunnelen.

en: <command>ssh -L 8000:server:25 intermediary</command> establishes an SSH session with the <replaceable>intermediary</replaceable> host and listens to local port 8000 (see <xref linkend="figure.ssh-L" />). For any connection established on this port, <command>ssh</command> will initiate a connection from the <replaceable>intermediary</replaceable> computer to port 25 on the <replaceable>server</replaceable>, and will bind both connections together.
nb-NO: <command>ssh -L 8000:server:25 intermediary</command> etablerer en SSH-økt med <replaceable>intermediary</replaceable>-verten, og lytter til lokal port 8000 (se <xref linkend="figure.ssh-L" />). For alle tilkoblinger som etableres til denne porten, vil <command>ssh</command> initiere en forbindelse fra <replaceable>intermediary</replaceable>-datamaskinen til port 25 på <replaceable>server</replaceable>-tjeneren, og vil binde begge tilknytninger sammen.

en: <command>ssh -R 8000:server:25 intermediary</command> also establishes an SSH session to the <replaceable>intermediary</replaceable> computer, but it is on this machine that <command>ssh</command> listens to port 8000 (see <xref linkend="figure.ssh-R" />). Any connection established on this port will cause <command>ssh</command> to open a connection from the local machine on to port 25 of the <replaceable>server</replaceable>, and to bind both connections together.
nb-NO: <command>ssh -R 8000:server:25 intermediary</command> etablerer også en SSH-økt til <replaceable>intermediary</replaceable>-datamaskinen, men det er på denne maskinen at <command>ssh</command> lytter til port 8000 (se <xref linkend="figure.ssh-R" />). Alle tilknytninger som er etablert til denne porten vil få <command>ssh</command> til å åpne en tilknytning fra den lokale maskinen til port 25 hos <replaceable>server</replaceable>-en, og til å binde begge tilknytninger sammen.

en: In both cases, connections are made to port 25 on the <replaceable>server</replaceable> host, which pass through the SSH tunnel established between the local machine and the <replaceable>intermediary</replaceable> machine. In the first case, the entrance to the tunnel is local port 8000, and the data move towards the <replaceable>intermediary</replaceable> machine before being directed to the <replaceable>server</replaceable> on the “public” network. In the second case, the input and output in the tunnel are reversed; the entrance is port 8000 on the <replaceable>intermediary</replaceable> machine, the output is on the local host, and the data are then directed to the <replaceable>server</replaceable>. In practice, the server is usually either the local machine or the intermediary. That way SSH secures the connection from one end to the other.
nb-NO: I begge tilfeller er forbindelsene lagt til port 25 på <replaceable> 1server</replaceable>-verten, og passerer gjennom SSH-tunnelen som er etablert mellom den lokale maskinen og <replaceable> 3intermediary</replaceable>-maskinen. I det første tilfellet er inngangen til tunnelen lokal port 8000, og dataene beveger seg mot <replaceable>intermediary</replaceable>-maskinen før de blir dirigert videre til <replaceable>server</replaceable>en i det «offentlige» nettverket. I det andre tilfellet er inngangen og utgangen i tunnelen reversert: Inngangen er port 8000 på <replaceable>intermediary</replaceable>-maskinen, og utdataene er på den lokale verten, og dataene blir deretter sendt til <replaceable>server</replaceable>-en. I praksis er tjeneren vanligvis enten den lokale maskinen eller mellomstasjonen. På den måten sikrer SSH forbindelsen fra den ene enden til den andre.

en: Forwarding a local port with SSH
nb-NO: Videresende en lokal port med SSH

en: Forwarding a remote port with SSH
nb-NO: Videresende en ekstern port med SSH

en: Using Remote Graphical Desktops
nb-NO: Å bruke eksterne grafiske skrivebord

en: VNC (Virtual Network Computing) allows remote access to graphical desktops.
nb-NO: VNC (Virtual Network Computing) tillater ekstern tilgang til grafiske skrivebord.

en: <primary>graphical desktop</primary><secondary>remote</secondary>
nb-NO: <primary>grafisk skrivebord</primary><secondary>eksternt</secondary>

en: <primary>remote graphical desktop</primary>
nb-NO: <primary>ekstern grafisk skrivebord</primary>

en: <primary>desktop, remote graphical desktop</primary>
nb-NO: <primary>skrivebord, ekstern grafisk skrivebord</primary>

en: This tool is mostly used for technical assistance; the administrator can see the errors that the user is facing, and show them the correct course of action without having to stand by them.
nb-NO: Dette verktøyet er mest brukt for teknisk assistanse; administratoren kan se feil som brukeren står overfor, og vise dem hva det er riktig å gjøre, uten å måtte stå ved siden av dem.

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

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

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

en: <emphasis>SECURITY</emphasis> VNC over SSH
nb-NO: <emphasis>SIKKERHET</emphasis> VNC over SSH

en: <primary>tunnel</primary><secondary>VNC</secondary>
nb-NO: <primary>tunnell</primary><secondary>VNC</secondary>

en: <primary>SSH</primary><secondary>tunnel</secondary><tertiary>VNC</tertiary>
nb-NO: <primary>SSH</primary><secondary>tunnell</secondary><tertiary>VNC</tertiary>

en: If you want to connect by VNC, and you don't want your data sent in clear text on the network, it is possible to encapsulate the data in an SSH tunnel (see <xref linkend="sect.ssh-port-forwarding" />). You simply have to know that VNC uses port 5900 by default for the first screen (called “localhost:0”), 5901 for the second (called “localhost:1”), etc.
nb-NO: Hvis du ønsker å koble til med VNC, og du ikke vil at dataene sendes i klartekst på nettverket, er det mulig å kapsle dataene i en SSH-tunnel (se <xref linkend="sect.ssh-port-forwarding" />). Du må bare vite at VNC bruker port 5900 som standard for det første skjermbildet (kalt «localhost:0»), 5901 for den andre (kalt «localhost:1»), osv.

en: The <command>ssh -L localhost:5901:localhost:5900 -N -T <replaceable>machine</replaceable></command> command creates a tunnel between local port 5901 in the localhost interface and port 5900 of the <replaceable>machine</replaceable> host. The first “localhost” restricts SSH to listening to only that interface on the local machine. The second “localhost” indicates the interface on the remote machine which will receive the network traffic entering in “localhost:5901”. Thus <command>vncviewer localhost:1</command> will connect the VNC client to the remote screen, even though you indicate the name of the local machine.
nb-NO: <command>ssh -L localhost:5901:localhost:5900 -N -T <replaceable>maskin</replaceable></command>-kommandoen oppretter en tunnel mellom lokal port 5901 i lokalvertgrensesnittet og til 5900-porten hos <replaceable>maskin</replaceable>-verten. Den første «lokalverten» begrenser SSH til å lytte bare til det grensesnittet på den lokale maskinen. Den andre «lokalverten» indikerer grensesnittet på den eksterne maskinen som skal motta nettverkstrafikk til «localvertst:5901». Dermed vil <command>vncviewer localhost:1</command> knytte VNC-klienten til den eksterne skjermen, selv om du anga navnet på den lokale maskinen.

en: When the VNC session is closed, remember to close the tunnel by also quitting the corresponding SSH session.
nb-NO: Når VNC-økten er lukket, må du huske å stenge tunnelen ved også å avslutte den tilsvarende SSH-økten.

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

en: <primary>manager</primary><secondary>display manager</secondary>
nb-NO: <primary>styrer</primary><secondary>skjermstyrer</secondary>

en: <primary>display manager</primary>
nb-NO: <primary>skjermstyrer</primary>

en: Managing Rights
nb-NO: Håndtering av rettigheter

en: <primary>permissions</primary>
nb-NO: <primary>rettigheter</primary>

en: <primary>device</primary><secondary>files</secondary>
nb-NO: <primary>enhet</primary><secondary>filer</secondary>

en: Linux is definitely a multi-user system, so it is necessary to provide a permission system to control the set of authorized operations on files and directories, which includes all the system resources and devices (on a Unix system, any device is represented by a file or directory). This principle is common to all Unix systems, but a reminder is always useful, especially as there are some interesting and relatively unknown advanced uses.
nb-NO: Linux er definitivt et flerbrukersystem (multi-user system), så det er nødvendig å gi et tillatelsessystem for å kontrollere et sett autoriserte operasjoner på filer og kataloger, for alle systemressurser og enheter (på et Unix-system, er enhver enhet representert ved en fil eller katalog). Dette prinsippet er felles for alle Unix-systemer, men en påminnelse er alltid nyttig, særlig fordi det er noen interessante og relativt ukjente, avanserte bruksmåter.

en: <primary>user</primary><secondary>owner</secondary>
nb-NO: <primary>bruker</primary><secondary>eier</secondary>

en: <primary>group</primary><secondary>owner</secondary>
nb-NO: <primary>gruppe</primary><secondary>eier</secondary>

en: <primary>owner</primary><secondary>user</secondary>
nb-NO: <primary>eier</primary><secondary>bruker</secondary>

en: <primary>owner</primary><secondary>group</secondary>
nb-NO: <primary>eier</primary><secondary>gruppe</secondary>

en: Each file or directory has specific permissions for three categories of users:
nb-NO: Hver fil eller katalog har egne tillatelser for tre kategorier av brukere:

en: its owner (symbolized by <literal>u</literal> as in “user”);
nb-NO: dens eier (symbolisert ved <literal>u</literal> som i «user»);

en: its owner group (symbolized by <literal>g</literal> as in “group”), representing all the members of the group;
nb-NO: dens eiergruppe (symbolisert med <literal>g</literal> som i «gruppe»), som representerer alle medlemmene i gruppen;

en: the others (symbolized by <literal>o</literal> as in “other”).
nb-NO: de andre (symbolisert med <literal>o</literal> som i «other»).

en: reading (symbolized by <literal>r</literal> as in “read”);
nb-NO: lesing (symbolisert med <literal>r</literal> som i «read»);

en: writing (or modifying, symbolized by <literal>w</literal> as in “write”);
nb-NO: skrive (eller modifisere, symbolisert ved <literal>w</literal> som i «write»);

en: executing (symbolized by <literal>x</literal> as in “eXecute”).
nb-NO: utføre (symbolisert med <literal>x</literal> som i «eXecute»).

en: <primary>read, right</primary>
nb-NO: <primary>lese, rettighet</primary>

en: <primary>write, right</primary>
nb-NO: <primary>skrive, rettighet</primary>

en: <primary>modification, right</primary>
nb-NO: <primary>endring, rettighet</primary>

en: <primary>execution, right</primary>
nb-NO: <primary>utføre, rettighet</primary>

en: In the case of a file, these rights are easily understood: read access allows reading the content (including copying), write access allows changing it, and execute access allows you to run it (which will only work if it is a program).
nb-NO: Når det gjelder en fil, er disse rettighetene lette å forstå: Lesetilgang tillater å lese innhold (inkludert kopiering), skrivetilgang tillater å endre den, og med kjøretilgang kan du kjøre den (som bare vil fungere hvis den er et program).

en: <emphasis>SECURITY</emphasis> <literal>setuid</literal> and <literal>setgid</literal> executables
nb-NO: <emphasis>SIKKERHET</emphasis> <literal>setuid</literal>- og <literal>setgid</literal>-programmer

en: <primary><literal>setuid</literal>, right</primary>
nb-NO: <primary><literal>setuid</literal>, rettighet</primary>

en: <primary><literal>setgid</literal>, right</primary>
nb-NO: <primary><literal>setgid</literal>, rettighet</primary>

en: Since a <literal>setuid</literal> root program is systematically run under the super-user identity, it is very important to ensure it is secure and reliable. Indeed, a user who would manage to subvert it to call a command of their choice could then impersonate the root user and have all rights on the system.
nb-NO: Ettersom et <literal>setuid</literal>-root-program systematisk kjøres under superbruker-identiteten, er det svært viktig å sikre at det er trygt og pålitelig. Faktisk, skulle en bruker klare å forbigå (undergrave) det for å bruke en kommando etter eget valg, kunne denne brukeren utgi seg for å være root-bruker, og få alle rettigheter til systemet.

en: If you require running a program under a different user or if a program requires higher permissions, the <command>sudo</command>, <command>su</command>, or <command>runuser</command> commands are usually better choices than using these bits (see <xref linkend="sect.sharing-admin-rights" />).
nb-NO: Hvis du må kjøre et program som en annen bruker eller hvis et program krever høyere tilganger, er <command>sudo</command>, <command>su</command>, eller <command>runuser</command>-kommandoene vanligvis bedre valg enn å bruke disse bit-ene (sjekk <xref linkend="sect.sharing-admin-rights" />).

en: A directory is handled differently. Read access gives the right to consult the list of its entries (files and directories), write access allows creating or deleting files, and execute access allows crossing through it (especially to go there with the <command>cd</command> command). Being able to cross through a directory without being able to read it gives permission to access the entries therein that are known by name, but not to find them if you do not know their existence or their exact name.
nb-NO: En katalog håndteres annerledes. Lesetilgang gir rett til å gjennomgå listen over oppføringene (filer og kataloger), skrivetilgang tillater å lage eller slette filer, og utføringstilgang tillater å krysse gjennom den (spesielt å gå dit med <command>cd</command>-kommandoen). Å kunne krysse gjennom en katalog uten å kunne lese den, gir tillatelse til å gå til de oppføringene som er kjent ved navn, men ikke til å finne dem hvis man ikke vet at de finnes, eller deres nøyaktige navn.

en: <emphasis>SECURITY</emphasis> <literal>setgid</literal> directory and <emphasis>sticky bit</emphasis>
nb-NO: <emphasis>SIKKERHET</emphasis> <literal>setgid</literal> katalog og <emphasis>sticky bit</emphasis>

en: <primary><literal>setgid</literal> directory</primary>
nb-NO: <primary><literal>setgid</literal> katalog</primary>

en: The <literal>setgid</literal> bit also applies to directories. Any newly-created item in such directories is automatically assigned the owner group of the parent directory, instead of inheriting the creator's main group as usual. This setup avoids the user having to change its main group (with the <command>newgrp</command> command) when working in a file tree shared between several users of the same dedicated group.
nb-NO: <literal>setgid</literal>-biten gjelder også kataloger. Ethvert nyopprettet element i slike kataloger blir automatisk knyttet til eiergruppen til den overordnede katalogen, i stedet for, som vanlig, å arve opphavsmannens (skaperens) hovedgruppe. Med dette oppsettet unngås det at brukeren trenger å endre sin hovedgruppe (med <command>newgrp</command>-kommandoen) når man arbeider i et fil-tre som deles mellom flere brukere i samme dediserte gruppe.

en: <primary>sticky bit</primary>
nb-NO: <primary>sticky/«klebrige» bit</primary>

en: The “sticky” bit (symbolized by the letter “t”) is a permission that is only useful in directories. It is especially used for temporary directories where everybody has write access (such as <filename>/tmp/</filename>): it restricts deletion of files so that only their owner (or the owner of the parent directory) can do it. Lacking this, everyone could delete other users' files in <filename>/tmp/</filename>.
nb-NO: «Sticky bit» - den «klebrige» bit-en - (symbolisert med bokstaven «t») er en tillatelse som bare er nyttig i kataloger. Det blir spesielt brukt for midlertidige kataloger, der alle har skrivetilgang (for eksempel <filename>/tmp/</filename>): Bit-en begrenser slettingen av filer slik at bare fileieren (eller eieren av den overordnede katalogen) kan gjøre det. Mangler denne, kan alle slette andre brukeres filer i <filename>/tmp/</filename>.

en: Three commands control the permissions associated with a file:
nb-NO: Tre kommandoer kontrollerer tillatelser knyttet til en fil:

en: <command>chown <replaceable>user</replaceable> <replaceable>file</replaceable></command> changes the owner of the file;
nb-NO: <command>chown <replaceable>bruker</replaceable> <replaceable>fil</replaceable></command> endrer eieren av filen;

en: <command>chgrp <replaceable>group</replaceable> <replaceable>file</replaceable></command> alters the owner group;
nb-NO: <command>chgrp <replaceable>gruppe</replaceable> <replaceable>fil</replaceable></command> endrer eiergruppen;

en: <command>chmod <replaceable>rights</replaceable> <replaceable>file</replaceable></command> changes the permissions for the file.
nb-NO: <command>chmod <replaceable>rettigheter</replaceable> <replaceable>fil</replaceable></command> endrer tillatelsene for filen.

en: There are two ways of presenting rights. Among them, the symbolic representation is probably the easiest to understand and remember. It involves the letter symbols mentioned above. You can define rights for each category of users (<literal>u</literal>/<literal>g</literal>/<literal>o</literal>), by setting them explicitly (with <literal>=</literal>), by adding (<literal>+</literal>), or subtracting (<literal>-</literal>). Thus the <literal>u=rwx,g+rw,o-r</literal> formula gives the owner read, write, and execute rights, adds read and write rights for the owner group, and removes read rights for other users. Rights not altered by the addition or subtraction in such a command remain unmodified. The letter <literal>a</literal>, for “all”, covers all three categories of users, so that <literal>a=rx</literal> grants all three categories the same rights (read and execute, but not write).
nb-NO: Det er to måter å presentere rettighetene på. Blant dem er den symbolske representasjon trolig den enkleste å forstå og huske. Det innebærer bokstavsymboler som nevnt ovenfor. Du kan definere rettigheter for hver kategori av brukere (<literal>u</literal>/<literal>g</literal>/<literal>o</literal>), ved å sette dem eksplisitt (ved <literal>=</literal>), ved å legge til (<literal>+</literal>), eller trekke fra (<literal>-</literal>). Dermed gir <literal>u=rwx,g+rw,o-r</literal>-formelen eieren lese-, skrive-, og utføringsrettigheter, legger til lese- og skriverettigheter for eiergruppen, og fjerner leserettigheter for andre brukere. Rettigheter som ikke er endret ved å legge til eller fjerne i en slik kommando, forblir uendret. Bokstaven <literal>a</literal>, for «alle», dekker alle tre kategorier brukere, slik at <literal>a=rx</literal> gir alle tre kategorier de samme rettigheter (lese og kjøre, men ikke skrive).

en: <primary>octal representation of rights</primary>
nb-NO: <primary>oktal representasjon av rettigheter</primary>

en: <primary>rights</primary><secondary>octal representation</secondary>
nb-NO: <primary>rettigheter</primary><secondary>oktal representasjon</secondary>

en: The (octal) numeric representation associates each right with a value: 4 for read, 2 for write, and 1 for execute. We associate each combination of rights with the sum of the figures. Each value is then assigned to different categories of users by putting them end to end in the usual order (owner, group, others).
nb-NO: Den (åttetalls-) numeriske representasjonen forbinder hver rettighet med en verdi: 4 for lese-, 2 for skrive, og 1 for å utføre. Vi forbinder hver kombinasjon av rettigheter med summen av tallene. Hver verdi blir deretter knyttet til ulike kategorier av brukere ved å sette dem side ved side (end to end)i den vanlige rekkefølgen (eier, gruppe, andre).

en: To represent special rights, you can prefix a fourth digit to this number according to the same principle, where the <literal>setuid</literal>, <literal>setgid</literal> and <literal>sticky</literal> bits are 4, 2 and 1, respectively. <command>chmod 4754</command> will associate the <literal>setuid</literal> bit with the previously described rights.
nb-NO: For å representere spesielle rettigheter kan du stille et fjerde siffer foran dette tallet etter samme prinsipp, der <literal>setuid</literal>, <literal>setgid</literal> og <literal>sticky</literal>-bitene er henholdsvis 4, 2 og 1. <command>chmod 4754</command> vil knytte <literal>setuid</literal>-biten til den tidligere beskrevne rettigheten.

en: Note that the use of octal notation only allows to set all the rights at once on a file; you cannot use it to simply add a new right, such as read access for the group owner, since you must take into account the existing rights and compute the new corresponding numerical value.
nb-NO: Merk at bruk av åttetallsystemet bare tillater å sette alle rettigheter samtidig i en fil; du kan ikke bruke den til å bare legge til en ny rett, slik som lesetilgang for gruppens eier, siden du må ta hensyn til eksisterende rettigheter, og beregne ny tilsvarende tallverdi.

en: <emphasis>TIP</emphasis> Recursive operation
nb-NO: <emphasis>TIPS</emphasis> Gjentatte operasjoner

en: Sometimes we have to change rights for an entire file tree. All the commands above have a <literal>-R</literal> option to operate recursively in sub-directories.
nb-NO: Noen ganger må vi endre rettighetene for et helt fil-tre. Alle kommandoene ovenfor har en <literal>-R</literal>-mulighet til å operere gjentakende (rekursivt) i underkataloger.

en: For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit <emphasis>only</emphasis> if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:
nb-NO: For mapper legger det til kjørbare tilganger for de(n) valgte bruker(ene). For filer, legger det til kjørbar bit <emphasis>kun</emphasis> hvis minst én av brukerne (eier, gruppe, eller andre) allerede har kjøringstilganger. Her kommer en demonstrasjon, siden dette kan være forvirrende:

en: <emphasis>GOING FURTHER</emphasis> <command>umask</command>
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> <command>umask</command>

en: <primary>rights</primary><secondary>mask</secondary>
nb-NO: <primary>rettigheter</primary><secondary>maske</secondary>

en: <primary>mask</primary><secondary>rights mask</secondary>
nb-NO: <primary>maske</primary><secondary>rettighetsmaske</secondary>

en: <primary>Access Control List</primary><see>ACL</see>
nb-NO: <primary>Tilgangskontrollister (Access Control List)</primary><see>ACL</see>

en: Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.
nb-NO: Mange filsystemer, f.eks. Btrfs, Ext3, Ext4, JFS, XFS, osv. støtter bruk av tilgangskontroll-lister (ACL-er). Disse utvider grunnleggende funksjoner for eierskap og tilganger (beskrevet i den forrige delen) og tillater mer finmasket kontroll over hvert objekt (fil). F.eks. Hvis en bruker ønsker å dele en fil med en annen og den brukeren kun skal kunne lese filen, men ikke skrive eller endre den.

en: For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the <literal>acl</literal> mount option - either in the <command>mount</command> command directly or in <filename>/etc/fstab</filename>. In the same way the usage of ACLs can be disabled by using the <literal>noacl</literal> mount option. For Ext* filesystems one can also use the <command>tune2fs -o [no]acl /dev/<replaceable>device</replaceable></command> command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (<citerefentry><refentrytitle><replaceable>filesystem</replaceable></refentrytitle> <manvolnum>5</manvolnum></citerefentry>) or in <citerefentry><refentrytitle>mount</refentrytitle> <manvolnum>8</manvolnum></citerefentry>.
nb-NO: For noen filsystemer er bruk av ACL-er påskrudd som forvalg (f.eks. Btrfs, Ext3, Ext4). For andre filsystemer eller eldre systemer må det skrus på ved bruk av <literal>acl</literal>-monteringsvalg. Enten i <command>mount</command>-kommandoen direkte, eller i <filename>/etc/fstab</filename>. På samme vis kan bruk av ACL-er skrus av ved bruk av <literal>noacl</literal>-monteringsvalget. For Ext*-filsystemer kan man også bruke <command>tune2fs -o [no]acl /dev/<replaceable>enhet</replaceable></command>-kommandoen for å skru av/på bruk av ACL-er som forvalg. De forvalgte verdiene for hvert filsystem er vanligvis å finne i deres homonym-manualsider i del 5 (<citerefentry><refentrytitle><replaceable>filsystem</replaceable></refentrytitle> <manvolnum>5</manvolnum></citerefentry>) eller i <citerefentry><refentrytitle>mount</refentrytitle> <manvolnum>8</manvolnum></citerefentry>.

en: If a file has ACLs set, the output of the <command>ls -l</command> command will show a plus-sign after the traditional permissions. When using ACLs, the <command>chmod</command> command behaves slightly different, and <command>umask</command> might be ignored. The extensive documentation, e.g. <citerefentry><refentrytitle>acl</refentrytitle> <manvolnum>5</manvolnum></citerefentry> contains more information.
nb-NO: Hvis en fil har ACL-er satt, vil utdata for <command>ls -l</command>-kommandoen vise et pluss-tegn etter de tradisjonelle tilgangene. Ved bruk av ACL-er oppfører <command>chmod</command> seg litt annerledes, og det kan hende at <command>umask</command> blir ignorert. Den detaljrike dokumentasjonen, f.eks. <citerefentry><refentrytitle>acl</refentrytitle> <manvolnum>5</manvolnum></citerefentry> har mer info.

en: Administration Interfaces
nb-NO: Administrasjonsgrensesnitt

en: <primary>interface</primary><secondary>administration interface</secondary>
nb-NO: <primary>grensesnitt</primary><secondary>administrasjonsgrensesnitt</secondary>

en: <primary>administration, interfaces</primary>
nb-NO: <primary>administrasjon, grensesnitt</primary>

en: Using a graphical interface for administration is interesting in various circumstances. An administrator does not necessarily know all the configuration details for all their services, and doesn't always have the time to go seeking out the documentation on the matter. A graphical interface for administration can thus accelerate the deployment of a new service. It can also simplify the setup of services which are hard to configure.
nb-NO: Å bruke et grafisk administrasjonsgrensesnitt er interessant i ulike situasjoner. En administrator kjenner ikke nødvendigvis alle oppsettsdetaljer for alle sine tjenester, og har ikke alltid tid til å gå igjennom dokumentasjonen i saken. Et grafisk administrasjonsgrensesnitt kan dermed akselerere utplassering av en ny tjeneste. Det kan også forenkle oppsettet av tjenester som er vanskelige å sette opp.

en: Such an interface is only an aid, and not an end in itself. In all cases, the administrator must master its behavior in order to understand and work around any potential problem.
nb-NO: Et slikt grensesnitt er bare et hjelpemiddel, og ikke et mål i seg selv. I alle tilfeller må administratoren beherske hvordan det virker for å forstå og løse mulige problemer.

en: Since no interface is perfect, you may be tempted to try several solutions. This is to be avoided as much as possible, since different tools are sometimes incompatible in their work methods. Even if they all aim to be very flexible and try to adopt the configuration file as a single reference, they are not always able to integrate external changes.
nb-NO: Siden ingen grensesnitt er perfekte, kan du bli fristet til å prøve ulike løsninger. Dette bør så mye som mulig unngås, siden arbeidsmetodikken til ulike verktøy ofte er uforenlige. Selv om alle har som mål å være svært fleksible, og prøve å adoptere oppsettsfilen som en eneste referanse, er de ikke alltid i stand til å integrere eksterne endringer.

en: Administrating on a Web Interface: <command>webmin</command>
nb-NO: Å administrere med et nettbrukergrensesnitt: <command>webmin</command>

en: This is, without a doubt, one of the most successful administration interfaces. It is a modular system managed through a web browser, covering a wide array of areas and tools. Furthermore, it is internationalized and available in many languages.
nb-NO: Dette er uten tvil et av de mest vellykkede administrasjonsgrensesnittene. Det er et modulsystem styrt gjennom en nettleser, og dekker et bredt spekter av områder og verktøy. Videre er det internasjonalisert, og tilgjengelig på mange språk.

en: Webmin dashboard
nb-NO: Webmin-kontrollpanel

en: There is, however, an unofficial package distributed on the <literal>webmin.com</literal> website. Contrary to the original Debian packages, this package is monolithic; all of its configuration modules are installed and activated by default, even if the corresponding service is not installed on the machine.
nb-NO: Det er imidlertid en uoffisiell pakke tilgjengelig fra nettsiden <literal>webmin.com</literal>. Til forskjell fra den opprinnelige Debian-pakken, er denne pakken monolittisk; alle oppsettsmodulene installeres og aktiveres som standard, selv om den tilsvarende tjenesten ikke er installert på maskinen.

en: <emphasis>SECURITY</emphasis> Changing the root password
nb-NO: <emphasis>SIKKERHET</emphasis> Endre rotpassordet

en: Webmin is used through a web interface, but it does not require Apache to be installed. Essentially, this software has its own integrated mini web server. This server listens by default on port 10000 and accepts secure HTTP connections.
nb-NO: Webmin brukes via et nettgrensesnitt, men krever ikke at Apache installeres. I hovedsak har dette programmet sin egen integrerte mini-nettjener. Denne tjeneren lytter som standard på port 10000, og aksepterer sikre HTTP-tilkoblinger.

en: Included modules cover a wide variety of services, among which:
nb-NO: De inkluderte moduler dekker et bredt spekter av tjenester, blant disse er:

en: bind: DNS server configuration (name service);
nb-NO: bind: DNS tjeneroppsett (navntjeneste);

en: postfix: SMTP server configuration (e-mail);
nb-NO: postfix: SMTP-tjeneroppsett (e-post);

en: dhcpd: DHCP server configuration;
nb-NO: dhcpd: DHCP-tjeneroppsett;

en: proftpd: FTP server configuration;
nb-NO: proftpd: FTP-tjeneroppsett;

en: samba: Samba file server configuration;
nb-NO: samba: Samba filtjeneroppsett;

en: software: installation or removal of software from Debian packages and system updates.
nb-NO: software: Installasjon eller fjerning av programvare fra Debian-pakker og systemoppdateringer .

en: The administration interface is available in a web browser at <literal>https://localhost:10000</literal>. Beware! Not all the modules are directly usable. Sometimes they must be configured by specifying the locations of the corresponding configuration files and some executable files (program). Frequently the system will politely prompt you when it fails to activate a requested module.
nb-NO: Administrasjonsgrensesnittet er tilgjengelig i en nettleser på <literal>https://localhost:10000</literal>. Pass opp! Ikke alle modulene kan brukes direkte. Noen ganger må de settes opp ved å angi plasseringen av de tilhørende oppsettsfiler og noen kjørbare filer (programmer). Ofte vil systemet høflig stille deg spørsmål når det ikke klarer å aktivere den modulen det er bedt om.

en: <emphasis>ALTERNATIVE</emphasis> GNOME control center
nb-NO: <emphasis>ALTERNATIV</emphasis> GNOME kontrollsenter

en: The GNOME project also provides multiple administration interfaces that are usually accessible via the “Settings” entry in the user menu on the top right. <command>gnome-control-center</command> is the main program that brings them all together but many of the system wide configuration tools are effectively provided by other packages (<emphasis role="pkg">accountsservice</emphasis>, <emphasis role="pkg">system-config-printer</emphasis>, etc.). Although they are easy to use, these applications cover only a limited number of base services: user management, time configuration, network configuration, printer configuration, and so on.
nb-NO: GNOME-prosjektet gir også flere administrasjonsgrensesnitt som vanligvis er tilgjengelig via «Innstillinger»-elementet i brukermenyen øverst til høyre. <command>gnome-control-center</command> er hovedprogrammet som bringer dem alle sammen, men mange av de brede systemomfattende oppsettsverktøy er effektivt levert av andre pakker (<emphasis role="pkg">accountsservice</emphasis>, <emphasis role="pkg">system-config-printer</emphasis>, etc.). Selv om de er enkle å bruke, dekker disse programmene kun et begrenset antall basetjenester: Brukeradministrasjon, tidsoppsett, nettverksoppsett, skriveroppsett, og så videre.

en: Configuring Packages: <command>debconf</command>
nb-NO: Oppsett av pakker: <command>debconf</command>

en: For most cases, these settings are very simple; only a few important variables in the configuration file are changed. These variables are often grouped between two “demarcation” lines so that reconfiguration of the package only impacts the enclosed area. In other cases, reconfiguration will not change anything if the script detects a manual modification of the configuration file, in order to preserve these human interventions (because the script can't ensure that its own modifications will not disrupt the existing settings).
nb-NO: I de fleste tilfeller er disse innstillingene veldig enkle; bare noen få viktige variabler i oppsettsfilen er endret. Disse variablene er ofte gruppert mellom to «avgrensnings»-linjer slik at nytt oppsett av pakken bare påvirker dette avgrensede området. I andre tilfeller vil ikke et nytt oppsett endre noe om skriptet oppdager en manuell endring i oppsettsfilen, for å kunne bevare disse manuelle inngrepene (fordi skriptet ikke kan sikre at egne tilpasninger ikke vil forstyrre eksisterende innstillinger).

en: <emphasis>DEBIAN POLICY</emphasis> Preserving changes
nb-NO: <emphasis>DEBIAN-RETNINGSLINJER</emphasis> Ta vare på endringer

en: <primary>Debian Project</primary><secondary>policy</secondary>
nb-NO: <primary>Debian-prosjekt</primary><secondary>praksis</secondary>

en: The Debian Policy expressly stipulates that everything should be done to preserve manual changes made to a configuration file, so more and more scripts take precautions when editing configuration files. The general principle is simple: the script will only make changes if it knows the status of the configuration file, which is verified by comparing the checksum of the file against that of the last automatically generated file. If they are the same, the script is authorized to change the configuration file. Otherwise, it determines that the file has been changed and asks what action it should take (install the new file, save the old file, or try to integrate the new changes with the existing file). This precautionary principle has long been unique to Debian, but other distributions have gradually begun to embrace it.
nb-NO: Debian-retningslinjene fastslår uttrykkelig at alt skal gjøres for å bevare manuelle endringer i en oppsettsfil, slik at flere og flere skript tar forholdsregler når du redigerer oppsettsfiler. Det generelle prinsippet er enkelt: Skriptet vil bare gjøre endringer hvis den kjenner statusen til oppsettsfilen, som er bekreftet ved å sammenligne kontrollsummen til filen mot den til den siste automatisk genererte filen. Hvis de er de samme, er skriptet autorisert til å endre oppsettsfilen. Ellers bestemmer det at filen er blitt endret, og spør hvilke tiltak det skal ta (installere den nye filen, lagre den gamle filen, eller prøve å integrere de nye endringene med den eksisterende filen). Dette føre var-prinsippet har lenge vært unikt for Debian, men andre distribusjoner har gradvis begynt å omfavne det.

en: The <command>ucf</command> program (from the Debian package of the same name) can be used to implement such a behavior.
nb-NO: Programmet <command>ucf</command> (fra Debian-pakken med samme navn) kan brukes til å få til at det skjer.

en: <command>syslog</command> System Events
nb-NO: <command>syslog</command> Systemhendelser

en: Principle and Mechanism
nb-NO: Prinsipp og mekanisme

en: The <command>rsyslogd</command> daemon is responsible for collecting service messages coming from applications and the kernel, then dispatching them into log files (usually stored in the <filename>/var/log/</filename> directory). It obeys the <filename>/etc/rsyslog.conf</filename> configuration file.
nb-NO: <command>rsyslogd</command>-bakgrunnsprosessen er ansvarlig for innsamling av servicemeldinger som kommer fra programmer og kjernen, og deretter ekspedere dem til loggfiler (vanligvis lagret i <filename>/var/log/</filename>-mappen). Den adlyder oppsettsfilen <filename>/etc/rsyslog.conf</filename>.

en: Each log message is associated with an application subsystem (called “facility” in the documentation):
nb-NO: Hver loggmelding er forbundet med en delsystemapplikasjon (kalt «facility» i dokumentasjonen):

en: <literal>auth</literal> and <literal>authpriv</literal>: for authentication;
nb-NO: <literal>auth</literal> og <literal>authpriv</literal>: for autentisering;

en: <literal>cron</literal>: comes from task scheduling services, <command>cron</command> and <command>atd</command>;
nb-NO: <literal>cron</literal>: kommer fra aktivitetsplanleggingstjenester,<command>cron</command> og <command>atd</command>;

en: <literal>daemon</literal>: affects a daemon without any special classification (DNS, NTP, etc.);
nb-NO: <literal>daemon</literal>: påvirker en bakgrunnsprosess uten noen spesiell klassifisering (DNS, NTP, etc.);

en: <literal>ftp</literal>: concerns the FTP server;
nb-NO: <literal>ftp</literal>: gjelder FTP-tjeneren;

en: <literal>kern</literal>: message coming from the kernel;
nb-NO: <literal>kern</literal>: melding kommer fra kjernen;

en: <literal>lpr</literal>: comes from the printing subsystem;
nb-NO: <literal>lpr</literal>: kommer fra skriver-delsystemet;

en: <literal>mail</literal>: comes from the e-mail subsystem;
nb-NO: <literal>mail</literal>: kommer fra e-post-delsystemet (the e-mail-subsystem);

en: <literal>news</literal>: Usenet subsystem message (especially from an NNTP — Network News Transfer Protocol — server that manages newsgroups);
nb-NO: <literal>news</literal>: Usenet delsystem-melding (spesielt fra en NNTP - Network News Transfer Protocol - tjener som styrer nyhetsgrupper);

en: <literal>syslog</literal>: messages from the <command>syslogd</command> server, itself;
nb-NO: <literal>syslog</literal>: meldinger fra <command>syslogd</command>-tjeneren selv;

en: <literal>user</literal>: user messages (generic);
nb-NO: <literal>user</literal>: brukermeldinger (generisk);

en: <literal>uucp</literal>: messages from the UUCP server (Unix to Unix Copy Program, an old protocol notably used to distribute e-mail messages);
nb-NO: <literal>uucp</literal>: meldinger fra UUCP-tjeneren (Unix til Unix Copy Program, en gammel protokoll som særlig brukes til å distribuere e-postmeldinger);

en: <literal>local0</literal> to <literal>local7</literal>: reserved for local use.
nb-NO: <literal>local0</literal> til <literal>local7</literal>: reservert for lokal bruk.

en: Each message is also associated with a priority level. Here is the list in decreasing order:
nb-NO: Hver melding er også knyttet til et prioritetsnivå. Her er listen i synkende rekkefølge:

en: <literal>emerg</literal>: “Help!” There is an emergency, the system is probably unusable.
nb-NO: <literal>emerg</literal>: «Hjelp!» Det er krise, systemet er sannsynligvis ubrukelig.

en: <literal>alert</literal>: hurry up, any delay can be dangerous, action must be taken immediately;
nb-NO: <literal>alert</literal>: skynd deg, enhver forsinkelse kan være farlig, det må handles umiddelbart;

en: <literal>crit</literal>: conditions are critical;
nb-NO: <literal>crit</literal>: forholdene er kritiske;

en: <literal>err</literal>: error;
nb-NO: <literal>err</literal>: feil;

en: <literal>warn</literal>: warning (potential error);
nb-NO: <literal>warn</literal>: advarsel (mulig fare);

en: <literal>notice</literal>: conditions are normal, but the message is important;
nb-NO: <literal>notice</literal>: forholdene er normale, men budskapet er viktig;

en: <literal>info</literal>: informative message;
nb-NO: <literal>info</literal>: informativt budskap;

en: <literal>debug</literal>: debugging message.
nb-NO: <literal>debug</literal>: feilsøkingsbudskap.

en: The Configuration File
nb-NO: Oppsettsfilen

en: <primary><command>rsyslogd</command></primary><secondary>configuration</secondary><seealso><filename>/etc/rsyslog.conf</filename></seealso>
nb-NO: <primary><command>rsyslogd</command></primary><secondary>oppsett</secondary><seealso><filename>/etc/rsyslog.conf</filename></seealso>

en: Syntax of the Selector
nb-NO: Syntaksen til velgeren (Selector)

en: The selector is a semicolon-separated list of <literal><replaceable>subsystem</replaceable>.<replaceable>priority</replaceable></literal> pairs (example: <literal>auth.notice;mail.info</literal>). An asterisk may represent all subsystems or all priorities (examples: <literal>*.alert</literal> or <literal>mail.*</literal>). Several subsystems can be grouped, by separating them with a comma (example: <literal>auth,mail.info</literal>). The priority indicated also covers messages of equal or higher priority; thus <literal>auth.alert</literal> indicates the <literal>auth</literal> subsystem messages of <literal>alert</literal> or <literal>emerg</literal> priority. Prefixed with an exclamation point (!), it indicates the opposite, in other words the strictly lower priorities; <literal>auth.!notice</literal>, thus, indicates messages issued from <literal>auth</literal>, with <literal>info</literal> or <literal>debug</literal> priority. Prefixed with an equal sign (=), it corresponds to precisely and only the priority indicated (<literal>auth.=notice</literal> only concerns messages from <literal>auth</literal> with <literal>notice</literal> priority).
nb-NO: Selektoren (velgeren) er en semikolon-delt liste med <literal><replaceable>subsystem</replaceable>.<replaceable>prioritet</replaceable></literal>-par (for eksempel: <literal>auth.notice;mail.info</literal>). En stjerne kan representere alle delsystemer, eller alle prioriteringer (eksempler: <literal>*.alert</literal>, eller <literal>mail.*</literal>). En stjerne kan representere alle delsystemer, eller alle prioriteringer (eksempler: <literal>auth,mail.info</literal>). Den indikerte prioriteten dekker også meldinger med tilsvarende, eller høyere prioritet; på den måten <literal>auth.alert</literal> indikerer <literal>auth</literal> subsystem-meldingene til <literal>alert</literal>, eller <literal>emerg</literal>-prioritet. Prefiks med et utropstegn (!), indikerer det motsatte, med andre ord de strengt tatt lavere prioriteringer; <literal>auth.!notice</literal>, og indikerer dermed meldinger utstedt fra <literal>auth</literal>, med <literal>info</literal> eller <literal>debug</literal>-prioritet. Prefiks med et likhetstegn (=), tilsvarer presist og bare den angitte prioriteten (<literal>auth.=notice</literal>, gjelder bare meldinger fra <literal>auth</literal> med <literal>notice</literal>-prioritet).

en: Each element in the list on the selector overrides previous elements. It is thus possible to restrict a set or to exclude certain elements from it. For example, <literal>kern.info;kern.!err</literal> means messages from the kernel with priority between <literal>info</literal> and <literal>warn</literal>. The <literal>none</literal> priority indicates the empty set (no priorities), and may serve to exclude a subsystem from a set of messages. Thus, <literal>*.crit;kern.none</literal> indicates all the messages of priority equal to or higher than <literal>crit</literal> not coming from the kernel.
nb-NO: Hvert element i Selektor-listen overstyrer tidligere elementer. Dermed er det mulig å avgrense et sett, eller å utestenge visse elementer fra den. For eksempel betyr <literal>kern.info;kern.!err</literal> meldinger fra kjernen med prioritet mellom <literal>info</literal> og <literal>warn</literal>. <literal>none</literal>-prioritet indikerer det tomme settet (ingen prioriteringer), og kan tjene til å utelukke et delsystem fra et sett med meldinger. Dermed indikerer <literal>*.crit;kern.none</literal> alle meldingene med prioritet lik eller høyere enn <literal>crit</literal>, som ikke kommer fra kjernen.

en: Syntax of Actions
nb-NO: Syntaks for handlinger

en: <emphasis>BACK TO BASICS</emphasis> The named pipe, a persistent pipe
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Den navngitte kanalen (named pipe), en vedvarende kanal

en: <primary>named pipe</primary>
nb-NO: <primary>navngitt kanal</primary>

en: A named pipe is a particular type of file that operates like a traditional pipe (the pipe that you make with the “|” symbol on the command line), but via a file. This mechanism has the advantage of being able to relate two unrelated processes. Anything written to a named pipe blocks the process that writes until another process attempts to read the data written. This second process reads the data written by the first, which can then resume execution.
nb-NO: En navngitt kanal er en spesiell type fil som virker som en tradisjonell kanal (kanalen som du lager med «|» -symbolet på kommandolinjen), men via en fil. Denne mekanismen har fordelen av å kunne forholde seg til to ikke-relaterte prosesser. Alt som er skrevet til en navngitt kanal blokkerer prosessen som skriver frem til en annen fremgangsmåte forsøker å lese de data som er skrevet. Denne andre prosessen leser de dataene som er skrevet av den første, som så kan gjenoppta kjøringen.

en: Such a file is created with the <command>mkfifo</command> command.
nb-NO: En slik fil er laget med <command>mkfifo</command>-kommandoen.

en: The various possible actions are:
nb-NO: De forskjellige mulige handlinger er:

en: add the message to a file (example: <filename>/var/log/messages</filename>);
nb-NO: å legge til en melding til en fil (eksempel: <filename>/var/log/messages</filename>);

en: send the message to a remote <command>syslog</command> server (example: <literal>@log.falcot.com</literal>);
nb-NO: sende meldingen til en ekstern <command>syslog</command>-tjener (eksempel: <literal>@log.falcot.com</literal>);

en: send the message to an existing named pipe (example: <literal>|/dev/xconsole</literal>);
nb-NO: send meldingen til en eksisterende navngitt kanal (eksempelvis: <literal>|/dev/xconsole</literal>);

en: send the message to one or more users, if they are logged in (example: <literal>root,rhertzog</literal>);
nb-NO: send meldingen til én eller flere brukere, hvis de er innlogget (eksempelvis:<literal>root,rhertzog</literal>);

en: send the message to all logged in users (example: <literal>*</literal>);
nb-NO: send meldingen til alle innloggede brukere (eksempelvis: <literal>*</literal>);

en: write the message in a text console (example: <literal>/dev/tty8</literal>).
nb-NO: skriv meldingen i en tekstkonsoll (eksempelvis: <literal>/dev/tty8</literal>).

en: <emphasis>SECURITY</emphasis> Forwarding logs
nb-NO: <emphasis>SIKKERHET</emphasis> Videresending av logger

en: <primary>log</primary><secondary>forwarding</secondary>
nb-NO: <primary>logg</primary><secondary>videresendelse</secondary>

en: It is a good idea to record the most important logs on a separate machine (perhaps dedicated for this purpose), since this will prevent any possible intruder from removing traces of their intrusion (unless, of course, they also compromise this other server). Furthermore, in the event of a major problem (such as a kernel crash), you have the logs available on another machine, which increases your chances of determining the sequence of events that caused the crash.
nb-NO: Det er en god idé å spille inn de viktigste loggene på en annen maskin (kanskje avsatt til dette formålet), siden dette vil hindre enhver mulig inntrenger fra å fjerne sporene av inntrengningen deres (med mindre, selvfølgelig, de også kompromitterer denne andre tjeneren). Videre har du, ved et stort problem (for eksempel et kjernekrasj), logger tilgjengelig på en annen maskin, noe som øker dine sjanser til å bestemme rekkefølgen av hendelser som forårsaket ulykken.

en: To accept log messages sent by other machines, you must reconfigure <emphasis>rsyslog</emphasis>: in practice, it is sufficient to activate the ready-for-use entries in <filename>/etc/rsyslog.conf</filename> (<literal>$ModLoad imudp</literal> and <literal>$UDPServerRun 514</literal>).
nb-NO: For å godta loggmeldinger sendt fra andre maskiner må du sette opp <emphasis>rsyslog</emphasis>: I praksis, er det tilstrekkelig å aktivere de ferdig-til-bruk oppføringene i <filename>/etc/rsyslog.conf</filename> (<literal>$ModLoad imudp</literal> og <literal>$UDPServerRun 514</literal>).

en: The <command>inetd</command> Super-Server
nb-NO: Super-server <command>inetd</command>

en: Inetd (often called “Internet super-server”) is a server of servers. It executes rarely used servers on demand, so that they do not have to run continuously.
nb-NO: Inetd (ofte kalt «Internet super-server») er en tjener for tjenere. Den kjører tjenere som sjeldent blir brukt, etter behov, slik at de slipper å kjøre kontinuerlig.

en: <primary>super-server</primary>
nb-NO: <primary>super-server (super-tjener)</primary>

en: The <filename>/etc/inetd.conf</filename> file lists these servers and their usual ports. The <command>inetd</command> command listens to all of them; when it detects a connection to any such port, it executes the corresponding server program.
nb-NO: <filename>/etc/inetd.conf</filename>-filen lister disse tjenerne og deres vanlige porter. Kommandoen <command>inetd</command> lytter til dem alle; Når den oppdager en forbindelse til en slik port, kjører den det tjenesteprogrammet som hører til.

en: Packages frequently want to register a new server in the <filename>/etc/inetd.conf</filename> file, but Debian Policy prohibits any package from modifying a configuration file that it doesn't own. This is why the <command>update-inetd</command> script (in the package with the same name) was created: It manages the configuration file, and other packages can thus use it to register a new server to the super-server's configuration.
nb-NO: Pakker ønsker ofte å registrere en ny tjener i <filename>/etc/inetd.conf</filename>-filen, men Debian Policy forhindrer alle pakker fra å modifisere en oppsettsfil som den ikke eier. Dette er grunnen til at <command>update-inetd</command>-skriptet (i pakken med samme navn) ble opprettet: Den håndterer oppsettfilen, og andre pakker kan dermed bruke den til å registrere en ny tjener i super-tjenerens oppsett.

en: Each significant line of the <filename>/etc/inetd.conf</filename> file describes a server through seven fields (separated by spaces):
nb-NO: Hver viktige linje i <filename>/etc/inetd.conf</filename>-filen beskriver en tjener med syv felt (atskilt med mellomrom):

en: The TCP or UDP port number, or the service name (which is mapped to a standard port number with the information contained in the <filename>/etc/services</filename> file).
nb-NO: TCP- eller UDP-portnummer, eller tjenestenavnet (som er koblet til et standard portnummer med den informasjonen som finnes i <filename>/etc/services</filename>-filen).

en: The socket type: <literal>stream</literal> for a TCP connection, <literal>dgram</literal> for UDP datagrams.
nb-NO: Type socket: <literal>stream</literal> for en TCP-forbindelse, <literal>dgram</literal> for UDP-datagrammer.

en: The options: two possible values: <literal>wait</literal> or <literal>nowait</literal>, to tell <command>inetd</command> whether it should wait or not for the end of the launched process before accepting another connection. For TCP connections, easily multiplexable, you can usually use <literal>nowait</literal>. For programs responding over UDP, you should use <literal>nowait</literal> only if the server is capable of managing several connections in parallel. You can suffix this field with a period, followed by the maximum number of connections authorized per minute (the default limit is 256).
nb-NO: Valgene: To mulige verdier: <literal>wait</literal> eller <literal>nowait</literal>, for å formidle til <command>inetd</command> om det skal vente eller ikke til slutten av den startede prosessen før du godtar en annen forbindelse. For TCP-forbindelser, enkelt multiplexbare, kan du vanligvis bruke <literal>nowait</literal>. For programmer som svarer over UDP, skal du bruke <literal>nowait</literal> bare hvis tjeneren kan håndtere flere tilkoblinger i parallell. Du kan ende dette feltet med et punktum, fulgt av det maksimale antall forbindelser autorisert pr. minutt (standardgrensen er 256).

en: The full path to the server program to execute.
nb-NO: Den fullstendige banen til det tjenerprogrammet som skal kjøres.

en: The arguments: this is a complete list of the program's arguments, including its own name (<literal>argv[0]</literal> in C).
nb-NO: Argumentene: Dette er en oversikt over programmets argumenter, inkludert dets eget navn (<literal>argv[0]</literal> in C).

en: Excerpt from <filename>/etc/inetd.conf</filename>
nb-NO: Utdrag fra <filename>/etc/inetd.conf</filename>

en: <emphasis>COMMUNITY</emphasis> Wietse Venema
nb-NO: <emphasis>FELLESSKAP</emphasis> Wietse Venema

en: <emphasis>ALTERNATIVE</emphasis> Other <command>inetd</command> commands
nb-NO: <emphasis>ALTERNATIV</emphasis> Andre <command>inetd</command>-kommandoer

en: Most of these alternatives share the same configuration file <filename>/etc/inetd.conf</filename>.
nb-NO: De fleste av disse alternativene deler samme oppsettsfil, <filename>/etc/inetd.conf</filename>.

en: Last but not least, it is even possible to emulate <command>inetd</command>'s behavior with <command>systemd</command>'s socket-activation mechanism (see <xref linkend="sect.systemd" />).
nb-NO: Sist, men ikke minst, er det også mulig å etterligne <command>inetd</command>s virke med <command>systemd</command>s socket-akiveringsmekanisme (se <xref linkend="sect.systemd" />).

en: Scheduling Tasks with <command>cron</command> and <command>atd</command>
nb-NO: Planlegge oppgaver i tide med <command>cron</command> og <command>atd</command>

en: <primary>scheduled commands</primary>
nb-NO: <primary>planlagte kommandoer</primary>

en: <primary>command scheduling</primary>
nb-NO: <primary>kommandoplanlegging</primary>

en: In a Unix system, many tasks are scheduled for regular execution:
nb-NO: I et Unix-system er mange oppgaver planlagt for regelmessig gjennomføring:

en: rotating the logs;
nb-NO: å rotere loggene;

en: updating the database for the <command>locate</command> program;
nb-NO: å oppdatere databasen for <command>locate</command>-programmet;

en: back-ups;
nb-NO: sikkerhetskopieringer;

en: maintenance scripts (such as cleaning out temporary files).
nb-NO: vedlikeholdsskript (for eksempel opprydding i midlertidige filer).

en: By default, all users can schedule the execution of tasks. Each user has thus their own <emphasis>crontab</emphasis> in which they can record scheduled commands. It can be edited by running <command>crontab -e</command> (its content is stored in the <filename>/var/spool/cron/crontabs/<replaceable>user</replaceable></filename> file).
nb-NO: Som standard kan alle brukere planlegge kjøring av oppgaver. Hver bruker har da sin egen <emphasis>crontab</emphasis>, der de kan legge planlagte kommandoer. Den kan redigeres ved å kjøre <command>crontab -e</command> (innholdet er lagret i <filename>/var/spool/cron/crontabs/<replaceable>bruker</replaceable></filename>-filen).

en: <emphasis>SECURITY</emphasis> Restricting <command>cron</command> or <command>atd</command>
nb-NO: <emphasis>SIKKERHET</emphasis> Begrense <command>cron</command> eller <command>atd</command>

en: The root user has their own <emphasis>crontab</emphasis>, but can also use the <filename>/etc/crontab</filename> file, or write additional <emphasis>crontab</emphasis> files in the <filename>/etc/cron.d</filename> directory. These last two solutions have the advantage of being able to specify the user identity to use when executing the command.
nb-NO: Rotbrukeren har sine egne <emphasis>crontab</emphasis>, men kan også bruke <filename>/etc/crontab</filename>-filen, eller skrive i tillegg <emphasis>crontab</emphasis>-filer i <filename>/etc/cron.d</filename>-mappen. Disse to siste løsningene har fordelen av å kunne spesifisere brukerens identitet når kommandoen utføres.

en: The <emphasis>cron</emphasis> package includes by default some scheduled commands that execute:
nb-NO: Pakken <emphasis>cron</emphasis> inkluderer som standard enkelte planlagte kommandoer som kjører:

en: programs in the <filename>/etc/cron.hourly/</filename> directory once per hour;
nb-NO: programmer i <filename>/etc/cron.hourly/</filename>-mappen en gang i timen;

en: programs in <filename>/etc/cron.daily/</filename> once per day;
nb-NO: programmer i <filename>/etc/cron.daily/</filename> en gang om dagen;

en: programs in <filename>/etc/cron.weekly/</filename> once per week;
nb-NO: programmer i <filename>/etc/cron.weekly/</filename> en gang per uke;

en: programs in <filename>/etc/cron.monthly/</filename> once per month.
nb-NO: programmer i <filename>/etc/cron.monthly/</filename> en gang per måned.

en: Many Debian packages rely on this service: by putting maintenance scripts in these directories, they ensure optimal operation of their services.
nb-NO: Mange Debian-pakker er avhengige av denne tjenesten: Ved å sette vedlikeholdsskript i disse katalogene, sikrer de optimal drift av sine tjenester.

en: Format of a <filename>crontab</filename> File
nb-NO: Format til en <filename>crontab</filename>-fil

en: <emphasis>TIP</emphasis> Text shortcuts for <command>cron</command>
nb-NO: <emphasis>TIPS</emphasis> Tekstsnarveier for <command>cron</command>

en: <command>cron</command> recognizes some abbreviations which replace the first five fields in a <filename>crontab</filename> entry. They correspond to the most classic scheduling options:
nb-NO: <command>cron</command> gjenkjenner noen forkortelser som erstatter de første fem feltene i en <filename>crontab</filename>-inngang. De svarer til de klassiske planleggingsalternativene:

en: <literal>@yearly</literal>: once per year (January 1, at 00:00);
nb-NO: <literal>@yearly</literal>: en gang i året (1. januar klokken 00:00);

en: <literal>@monthly</literal>: once per month (the 1st of the month, at 00:00);
nb-NO: <literal>@monthly</literal>: en gang per måned (den første i måneden, kl. 00:00);

en: <literal>@weekly</literal>: once per week (Sunday at 00:00);
nb-NO: <literal>@weekly</literal>: en gang i uken (søndag kl 00:00);

en: <literal>@daily</literal>: once per day (at 00:00);
nb-NO: <literal>@daily</literal>: en gang hver dag (kl 00:00);

en: <literal>@hourly</literal>: once per hour (at the beginning of each hour).
nb-NO: <literal>@hourly</literal>: en gang i timen (ved begynnelsen av hver time).

en: <emphasis>SPECIAL CASE</emphasis> <command>cron</command> and daylight savings time
nb-NO: <emphasis>KONKRET SAK</emphasis> <command>cron</command> og sommertid

en: In Debian, <command>cron</command> takes the time change (for Daylight Savings Time, or in fact for any significant change in the local time) into account as best as it can. Thus, the commands that should have been executed during an hour that never existed (for example, tasks scheduled at 2:30 am during the Spring time change in France, since at 2:00 am the clock jumps directly to 3:00 am) are executed shortly after the time change (thus around 3:00 am DST). On the other hand, in autumn, when commands would be executed several times (2:30 am DST, then an hour later at 2:30 am standard time, since at 3:00 am DST the clock turns back to 2:00 am) are only executed once.
nb-NO: I Debian tar <command>cron</command> hensyn til tidsendringen (for sommertid, eller faktisk for alle vesentlige endringer i lokal tid) som best den kan. Dermed kjøres kommandoene som burde vært utført i løpet av en time som aldri har eksistert (for eksempel oppgaver planlagt til 02:30 under vårens tidsendring i Frankrike, ettersom klokken 02:00 hopper direkte til 03:00) kort tid etter den tidsendringen (altså rundt 03:00 sommertid). På den andre siden, om høsten, når kommandoer ville bli kjørt flere ganger (02:30 sommertid, så en time senere på 02:30 normert tid, så på 03:00 sommertid for klokken går tilbake til 02:00) blir bare kjørt én gang.

en: Be careful, however, if the order in which the different scheduled tasks and the delay between their respective executions matters, you should check the compatibility of these constraints with <command>cron</command>'s behavior; if necessary, you can prepare a special schedule for the two problematic nights per year.
nb-NO: Vær forsiktig, for hvis rekkefølgen for når de ulike tidfestede oppgavene, og forsinkelsen mellom de respektive kjøringene betyr noe, bør du sjekke kompatibiliteten til disse begrensningene opp mot hvordan <command>cron</command> virker; Hvis det er nødvendig, kan du forberede en spesiell tidsplan for de to årlige, problematiske nettene.

en: the value for the hour (from 0 to 23);
nb-NO: verdien for timen (nummer 0 til 23);

en: the value for the day of the month (from 1 to 31);
nb-NO: verdien for dagen i måneden (fra 1 til 31);

en: the value for the month (from 1 to 12);
nb-NO: verdien for måneden (fra 1 til 12);

en: the value for the day of the week (from 0 to 7, 1 corresponding to Monday, Sunday being represented by both 0 and 7; it is also possible to use the first three letters of the name of the day of the week in English, such as <literal>Sun</literal>, <literal>Mon</literal>, etc.);
nb-NO: verdien for ukedagen (0-7, 1 tilsvarer mandag, søndag korresponderer med både 0 og 7; Det er også mulig å bruke de tre første bokstavene i navnet på ukedagen på engelsk, som for eksempel <literal>Sun</literal>, <literal>Mon</literal>, etc.);

en: the user name under whose identity the command must be executed (in the <filename>/etc/crontab</filename> file and in the fragments located in <filename>/etc/cron.d/</filename>, but not in the users' own crontab files);
nb-NO: brukernavnet hvis identitet kommandoen må kjøres i (i <filename>/etc/crontab</filename>-filen, og i fragmentene som ligger i <filename>/etc/cron.d/</filename>, men ikke i brukerens egne crontab-filer);

en: the command to execute (when the conditions defined by the first five columns are met).
nb-NO: kommandoen kjøres (når vilkårene som er definert i de fem første kolonnene er oppfylt).

en: All these details are documented in the <citerefentry><refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum></citerefentry> man page.
nb-NO: Alle disse detaljene er dokumentert i manualsiden <citerefentry><refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum></citerefentry>.

en: <emphasis>TIP</emphasis> Executing a command on boot
nb-NO: <emphasis>TIPS</emphasis> Kjøre en kommando ved oppstart

en: To execute a command a single time, just after booting the computer, you can use the <literal>@reboot</literal> macro (a simple restart of <command>cron</command> does not trigger a command scheduled with <literal>@reboot</literal>). This macro replaces the first five fields of an entry in the <emphasis>crontab</emphasis>.
nb-NO: For å kjøre en kommando en eneste gang like etter oppstart av datamaskinen, kan du bruke <literal>@reboot</literal> makro (en enkelt omstart av <command>cron</command> utløser ikke en kommando planlagt med <literal>@reboot</literal>). Denne makroen erstatter de første fem feltene i en oppføring i <emphasis>crontab</emphasis>.

en: <emphasis>ALTERNATIVE</emphasis> Emulating <command>cron</command> with <command>systemd</command>
nb-NO: <emphasis>ALTERNATIV</emphasis> Å etterligne <command>cron</command> med <command>systemd</command>

en: It is possible to emulate part of <command>cron</command>'s behavior with <command>systemd</command>'s timer mechanism (see <xref linkend="sect.systemd" />).
nb-NO: Det er mulig å etterligne en del av <command>cron</command>s oppgaver med <command>systemd</command>s timermekanisme (se <xref linkend="sect.systemd" />).

en: Using the <command>at</command> Command
nb-NO: Bruk av <command>at</command>-kommandoen

en: An alternative syntax postpones the execution for a given duration: <command>at now + <replaceable>number</replaceable> <replaceable>period</replaceable></command>. The <replaceable>period</replaceable> can be <literal>minutes</literal>, <literal>hours</literal>, <literal>days</literal>, or <literal>weeks</literal>. The <replaceable>number</replaceable> simply indicates the number of said units that must elapse before execution of the command.
nb-NO: En alternativ syntaks utsetter gjennomføringen med en bestemt varighet: <command>at now + <replaceable>nummer</replaceable> <replaceable>varighet</replaceable></command>. <replaceable>varighet</replaceable> kan være <literal>minutes</literal>, <literal>hours</literal>, <literal>days</literal>, eller <literal>weeks</literal>. <replaceable>nummer</replaceable> indikerer rett og slett antallet av de nevnte enheter som må ha passert før kommandoen utføres.

en: To cancel a task scheduled by <command>cron</command>, simply run <command>crontab -e</command> and delete the corresponding line in the <emphasis>crontab</emphasis> file. For <command>at</command> tasks, it is almost as easy: run <command>atrm <replaceable>task-number</replaceable></command>. The task number is indicated by the <command>at</command> command when you scheduled it, but you can find it again with the <command>atq</command> command, which gives the current list of scheduled tasks.
nb-NO: For å avbryte en tidfestet oppgave med <command>cron</command>, kjør ganske enkelt <command>crontab -e</command>, og slett den tilsvarende linjen i <emphasis>crontab</emphasis>-filen. For <command>at</command>-oppgaver, er det nesten like lett; kjør <command>atrm <replaceable>oppgavenummer</replaceable></command>. Oppgavenummeret er indikert av <command>at</command>-kommandoen når du har tidfestet den, men du kan finne det igjen med <command>atq</command>-kommandoen, som gir den gjeldende listen over tidfestede oppgaver.

en: Scheduling Asynchronous Tasks: <command>anacron</command>
nb-NO: Asynkrone oppgaver på timeplanen: <command>anacron</command>

en: <command>anacron</command> is the daemon that completes <command>cron</command> for computers that are not on at all times. Since regular tasks are usually scheduled for the middle of the night, they will never be executed if the computer is off at that time. The purpose of <command>anacron</command> is to execute them, taking into account periods in which the computer is not working.
nb-NO: <command>anacron</command> er bakgrunnsprosessen som fullfører <command>cron</command> for datamaskiner som ikke er på hele tiden. Siden vanlige oppgaver vanligvis er planlagt midt på natten, vil de aldri bli kjørt hvis maskinen er slått av på den tiden. Meningen med <command>anacron</command> er å utføre dem, når det tas hensyn til perioder når datamaskinen ikke er på.

en: Please note that <command>anacron</command> will frequently execute such activity a few minutes after booting the machine, which can render the computer less responsive. This is why the tasks in the <filename>/etc/anacrontab</filename> file are started with the <command>nice</command> command, which reduces their execution priority and thus limits their impact on the rest of the system. Beware, the format of this file is not the same as that of <filename>/etc/crontab</filename>; if you have particular needs for <command>anacron</command>, see the <citerefentry><refentrytitle>anacrontab</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page.
nb-NO: Noter gjerne at <command>anacron</command> ofte vil utføre slik aktivitet noen få minutter etter oppstart av maskinen, noe som kan gjøre datamaskinen mindre tilgjengelig. Dette er grunnen til at oppgavene i <filename>/etc/anacrontab</filename>-filen er startet med <command>nice</command>-kommandoen, noe som reduserer kjøreprioriteten deres, og dermed begrenser innvirkningen deres på resten av systemet. Vær klar over at formatet på denne filen ikke er det samme som for <filename>/etc/crontab</filename>. Har du bestemte behov for <command>anacron</command>, se manualsiden <citerefentry><refentrytitle>anacrontab</refentrytitle> <manvolnum>5</manvolnum></citerefentry>.

en: <emphasis>BACK TO BASICS</emphasis> Priorities and <command>nice</command>
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Prioriteter og <command>nice</command>

en: <command>nice</command> works with levels of “niceness”: the positive levels (from 1 to 19) progressively lower the priority, while the negative levels (from -1 to -20) will increase it — but only root can use these negative levels. Unless otherwise indicated (see the <citerefentry><refentrytitle>nice</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page), <command>nice</command> increases the current level by 10.
nb-NO: <command>nice</command> arbeider med nivåer av «snillhet»; de positive nivåene (fra 1 til 19) senker prioriteten progressivt, mens de negative nivåer (fra -1 til -20) vil øke det - men bare rot kan bruke disse negative nivåer. Dersom ikke annet er angitt (se håndboken side <citerefentry><refentrytitle>nice</refentrytitle> <manvolnum>1</manvolnum></citerefentry>), <command>nice</command> øker det gjeldende nivået med 10.

en: If you discover that an already running task should have been started with <command>nice</command> it is not too late to fix it; the <command>renice</command> command changes the priority of an already running process, in either direction (but reducing the “niceness” of a process is reserved for the root user).
nb-NO: Hvis du oppdager at en allerede kjørende oppgave skulle vært i gang med <command>nice</command>, er det ikke for sent å ordne det; <command>renice</command>-kommandoen endrer prioritet for en prosess som allerede kjører, i begge retninger (men å redusere «snillheten» for en prosess er forbeholdt rotbrukeren).

en: Installation of the <emphasis role="pkg">anacron</emphasis> package deactivates execution by <command>cron</command> of the scripts in the <filename>/etc/cron.hourly/</filename>, <filename>/etc/cron.daily/</filename>, <filename>/etc/cron.weekly/</filename>, and <filename>/etc/cron.monthly/</filename> directories. This avoids their double execution by <command>anacron</command> and <command>cron</command>. The <command>cron</command> command remains active and will continue to handle the other scheduled tasks (especially those scheduled by users).
nb-NO: Installasjon av <emphasis role="pkg">anacron</emphasis>-pakken deaktiverer kjøring med <command>cron</command> av skriptene i <filename>/etc/cron.hourly/</filename>, <filename>/etc/cron.daily/</filename>, <filename>/etc/cron.weekly/</filename>, og <filename>/etc/cron.monthly/</filename>-mappene. Dette hindrer dobbel kjøring av <command>anacron</command> og <command>cron</command>. <command>cron</command>-kommandoen er fortsatt aktiv, og vil fortsette å håndtere de andre planlagte oppgavene (spesielt de planlagt av brukere).

en: Quotas
nb-NO: Kvoter

en: <primary>quota</primary>
nb-NO: <primary>kvote</primary>

en: The quota system allows limiting disk space allocated to a user or group of users. To set it up, you must have a kernel that supports it (compiled with the <varname>CONFIG_QUOTA</varname> option) — as is the case with Debian kernels. The quota management software is found in the <emphasis role="pkg">quota</emphasis> Debian package.
nb-NO: Kvotesystemet kan begrense diskplass avsatt til en bruker, eller gruppe av brukere. For å sette det opp må du ha en kjerne som støtter det (utarbeidet med <varname>CONFIG_QUOTA</varname> alternativ) - som er tilfellet med Debian-kjernene. Kvotehåndteringsprogrammet finnes i <emphasis role="pkg">quota</emphasis> Debian-pakken.

en: To activate quota in a filesystem, you have to indicate the <literal>usrquota</literal> and <literal>grpquota</literal> options in <filename>/etc/fstab</filename> for the user and group quotas, respectively. Rebooting the computer will then update the quotas in the absence of disk activity (a necessary condition for proper accounting of already used disk space).
nb-NO: For å aktivere kvoter i et filsystem må du angi <literal>usrquota</literal> og <literal>grpquota</literal>-valgene i <filename>/etc/fstab</filename> for henholdsvis bruker- og gruppekvotene. Deretter vil omstart av maskinen oppdatere kvotene når det ikke er diskaktivitet (en nødvendig betingelse for riktig bokføring av allerede brukt diskplass).

en: The <command>edquota <replaceable>user</replaceable></command> (or <command>edquota -g <replaceable>group</replaceable></command>) command allows you to change the limits while examining current disk space usage.
nb-NO: Kommandoen <command>edquota <replaceable>bruker</replaceable></command> (eller <command>edquota -g <replaceable>gruppe</replaceable></command>) tillater deg å endre grensene mens bruken av gjeldende diskplass undersøkes.

en: <emphasis>GOING FURTHER</emphasis> Defining quotas with a script
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Å definere kvoter med et skript

en: The <command>setquota</command> program can be used in a script to automatically change many quotas. Its <citerefentry><refentrytitle>setquota</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page details the syntax to use.
nb-NO: Programmet <command>setquota</command> kan bli brukt i et skript for automatisk å forandre mange kvoter. Dets manualside <citerefentry><refentrytitle>setquota</refentrytitle> <manvolnum>8</manvolnum></citerefentry> gir detaljer om syntaksen som kan brukes.

en: The quota system allows you to set four limits:
nb-NO: Kvotesystemet lar deg sette fire grenser:

en: A “soft” limit can be temporarily exceeded; the user will simply be warned that they are exceeding the quota by the <command>warnquota</command> command, which is usually invoked by <command>cron</command>. A “hard” limit can never be exceeded: the system will refuse any operation that will cause a hard quota to be exceeded.
nb-NO: En «myk» grense kan overskrides midlertidig; brukeren vil bare bli advart om at de overstiger kvoten fra <command>warnquota</command>-kommandoen, som vanligvis er utløst av <command>cron</command>. En «hard» grense kan aldri bli overskredet: Systemet vil nekte enhver operasjon som vil føre til at en hard kvote blir overskredet.

en: <emphasis>VOCABULARY</emphasis> Blocks and inodes
nb-NO: <emphasis>ORDFORRÅD</emphasis> Blokker og inoder

en: <primary>block (disk)</primary>
nb-NO: <primary>blokk (disk)</primary>

en: The filesystem divides the hard drive into blocks — small contiguous areas. The size of these blocks is defined during creation of the filesystem, and generally varies between 1 and 8 kibibytes.
nb-NO: Filsystemet deler harddisken inn i blokker - små sammenhengende områder. Størrelsen på disse blokkene er definert ved etableringen av filsystemet, og varierer vanligvis mellom 1 og 8 kibibytes.

en: A block can be used either to store the real data of a file, or for meta-data used by the filesystem. Among this meta-data, you will especially find the inodes. An inode uses a block on the hard drive (but this block is not taken into consideration in the block quota, only in the inode quota), and contains both the information on the file to which it corresponds (name, owner, permissions, etc.) and the pointers to the data blocks that are actually used. For very large files that occupy more blocks than it is possible to reference in a single inode, there is an indirect block system; the inode references a list of blocks that do not directly contain data, but another list of blocks.
nb-NO: En blokk kan enten brukes til å lagre de virkelige dataene fra en fil, eller til metadata som brukes av filsystemet. Blant disse metadataene vil du særlig finne inoder. En inode bruker en blokk på harddisken (men denne blokken er det ikke tatt hensyn til i blokkvoten, bare i inodekvoten), og inneholder både informasjon om filen som den tilsvarer (navn, eier, tillatelser, etc .) og pekere til datablokker som faktisk brukes. For meget store filer som opptar flere blokker enn det er mulig å referere til i en enkelt inode, er det et indirekte blokkeringssystem; inoden refererer til en liste med blokker som ikke direkte inneholder data, men en annen liste med blokker.

en: With the <command>edquota -t</command> command, you can define a maximum authorized “grace period” within which a soft limit may be exceeded. After this period, the soft limit will be treated like a hard limit, and the user will have to reduce their disk space usage to within this limit in order to be able to write anything to the hard drive.
nb-NO: Med <command>edquota -t</command>-kommandoen, kan du definere en maksimal tillatt «nådeperiode» («grace period») innenfor hvilken en myk grense kan overskrides. Etter denne perioden, vil den myke grensen bli behandlet som en hard grense, og brukeren vil måtte redusere sin bruk av diskplass til denne grensen, for å kunne skrive noe på harddisken.

en: <emphasis>GOING FURTHER</emphasis> Setting up a default quota for new users
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Setting av utgangskvote for nye brukere

en: To automatically setup a quota for new users, you have to configure a template user (with <command>edquota</command> or <command>setquota</command>) and indicate their user name in the <varname>QUOTAUSER</varname> variable in the <filename>/etc/adduser.conf</filename> file. This quota configuration will then be automatically applied to each new user created with the <command>adduser</command> command.
nb-NO: For å sette opp en kvote til nye brukere automatisk må du sette opp en brukermal (med <command>edquota</command>, eller <command>setquota</command>), og indikere brukernavnet deres i <varname>QUOTAUSER</varname>-variabelen i <filename>/etc/adduser.conf</filename>-filen. Dette kvoteoppsettet vil da automatisk bli brukt på hver nye bruker som opprettes med <command>adduser</command>-kommandoen.

en: <primary>backup</primary>
nb-NO: <primary>sikkerhetskopi</primary>

en: <primary>restoration</primary>
nb-NO: <primary>restaurering</primary>

en: Making backups is one of the main responsibilities of any administrator, but it is a complex subject, involving powerful tools which are often difficult to master.
nb-NO: Sikkerhetskopiering er en av hovedoppgavene for en administrator, men det er et komplekst tema, som involverer kraftige verktøy som det ofte er vanskelig å mestre.

en: Debian contains dozens of other backup software covering all possible use cases, as you can easily confirm with <command>apt-cache search backup</command>.
nb-NO: Debian inneholder mange andre programmer for sikkerhetskopiering, som dekker alle mulige brukstilfeller. Disse kan du sjekke selv med <command>apt-cache search backup</command>.

en: Rather than detailing some of them, this section will present the thoughts of the Falcot Corp administrators when they defined their backup strategy.
nb-NO: Snarere enn en detaljert gjennomgang av noen av dem, vil dette avsnittet presentere de tanker Falcot Corp-administratorene har når de definerer sin strategi for sikkerhetskopiering.

en: At Falcot Corp, backups have two goals: recovering erroneously deleted files, and quickly restoring any computer (server or desktop) whose hard drive has failed.
nb-NO: Hos Falcot Corp har sikkerhetskopiering to mål: Å gjenopprette feilaktig slettede filer, og raskt gjenopprette en datamaskin (tjener eller desktop) hvis harddisken har feilet.

en: Backing Up with <command>rsync</command>
nb-NO: Sikkerhetskopiering med <command>rsync</command>

en: Backups on tape having been deemed too slow and costly, data will be backed up on hard drives on a dedicated server, on which the use of software RAID (see <xref linkend="sect.raid-soft" />) will protect the data from hard drive failure. Desktop computers are not backed up individually, but users are advised that their personal account on their department's file server will be backed up. The <command>rsync</command> command (from the package of the same name) is used daily to back up these different servers.
nb-NO: Da sikkerhetskopier på tape har blitt ansett for å være tregt og dyrt, blir data sikkerhetskopiert på harddisker på en øremerket tjener, der bruk av programvare-RAID (se <xref linkend="sect.raid-soft" />) vil beskytte data fra feil på harddisken. Stasjonære datamaskiner støttes ikke opp individuelt, men brukerne gjøres oppmerksom på at deres personlige konto på deres avdelings filtjener blir sikkerhetskopiert. <command>rsync</command>-kommando (fra pakken med samme navn) brukes daglig for å sikkerhetskopiere disse forskjellige tjenerne.

en: <emphasis>BACK TO BASICS</emphasis> The hard link, a second name for the file
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Hardlenken, et annet navn for filen

en: <primary>link</primary><secondary>hard link</secondary>
nb-NO: <primary>lenke</primary><secondary>hardlenke</secondary>

en: <primary>hard link</primary>
nb-NO: <primary>hardlenke</primary>

en: A hard link, as opposed to a symbolic link, cannot be differentiated from the linked file. Creating a hard link is essentially the same as giving an existing file a second name. This is why the deletion of a hard link only removes one of the names associated with the file. As long as another name is still assigned to the file, the data therein remain present on the filesystem. It is interesting to note that, unlike a copy, the hard link does not take up additional space on the hard drive.
nb-NO: En hard lenke, i motsetning til en symbolsk lenke, kan ikke skilles fra den lenkede filen. Å lage en hard lenke er egentlig det samme som å gi en eksisterende fil et navn til. Dette er grunnen til sletting av en hard lenke bare fjerner ett av navnene forbundet med filen. Så lenge et annet navn er fortsatt tildelt filen, er dataene fortsatt til stede i filsystemet. Det er interessant å merke seg at, i motsetning til en kopi, tar ikke den harde lenken opp tilleggsplass på harddisken.

en: A hard link is created with the <command>ln <replaceable>target</replaceable> <replaceable>link</replaceable></command> command. The <replaceable>link</replaceable> file is then a new name for the <replaceable>target</replaceable> file. Hard links can only be created on the same filesystem, while symbolic links are not subject to this limitation.
nb-NO: En hard lenke lages med <command>ln <replaceable>mål</replaceable> <replaceable>lenke</replaceable></command>-kommandoen. <replaceable>lenke</replaceable>-filen er så det nye navnet for <replaceable>mål</replaceable>-filen. Harde lenker kan bare opprettes på samme filsystem, mens symbolske lenker er ikke underlagt denne begrensningen.

en: The available hard drive space prohibits implementation of a complete daily backup. As such, the <command>rsync</command> command is preceded by a duplication of the content of the previous backup with hard links, which prevents usage of too much hard drive space. The <command>rsync</command> process then only replaces files that have been modified since the last backup. With this mechanism a great number of backups can be kept in a small amount of space. Since all backups are immediately available and accessible (for example, in different directories of a given share on the network), you can quickly make comparisons between two given dates.
nb-NO: Den tilgjengelige harddiskplassen forbyr gjennomføring av en komplett daglig sikkerhetskopiering. Som sådan, <command>rsync</command>-kommandoen innledes med en duplisering av innholdet i den forrige sikkerhetskopien med harde lenker, som forhindrer bruk av for mye plass på harddisken. Prosessen <command>rsync</command> erstatter da bare filer som har blitt endret siden siste backup. Med denne mekanismen kan et stort antall sikkerhetskopier holdes på en liten mengde plass. Ettersom alle sikkerhetskopier er umiddelbart tilgjengelige, og med adgang (for eksempel i ulike kataloger av en gitt andel på nettverket), kan du raskt gjøre sammenligninger mellom to gitte datoer.

en: <primary>copy, backup copy</primary>
nb-NO: <primary>kopiere, sikkerhetskopi</primary>

en: <primary>backup</primary><secondary>copy</secondary>
nb-NO: <primary>sikkerhetskopi (backup)</primary><secondary>kopiere</secondary>

en: This backup mechanism is easily implemented with the <command>dirvish</command> program. It uses a backup storage space (“bank” in its vocabulary) in which it places timestamped copies of sets of backup files (these sets are called “vaults” in the dirvish documentation).
nb-NO: Denne sikkerhetskopi-mekanismen kan lett implementeres med <command>dirvish</command>-programmet. Den bruker en sikkerhetskopi-lagringsplass («bank» i sitt vokabular) hvor det plasserer tidsmerkede kopier av settene med sikkerhetskopi-filer (disse settene er kalt «vaults» i dirvish-dokumentasjon).

en: The main configuration is in the <filename>/etc/dirvish/master.conf</filename> file. It defines the location of the backup storage space, the list of “vaults” to manage, and default values for expiration of the backups. The rest of the configuration is located in the <filename><replaceable>bank</replaceable>/<replaceable>vault</replaceable>/dirvish/default.conf</filename> files and contains the specific configuration for the corresponding set of files.
nb-NO: Hovedoppsettet er i <filename>/etc/dirvish/master.conf</filename>-filen. Den definerer plasseringen av lagringsplassen for sikkerhetskopien, listen over «vaults» for å administere, og standardverdier for utløpstidspunktet for sikkerhetskopier. Resten av oppsettet er plassert i <filename><replaceable>bank</replaceable>/<replaceable>vault</replaceable>/dirvish/default.conf</filename>-filer, og inneholder det spesifikke oppsettet for det tilsvarende settet med filer.

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

en: <emphasis>IN PRACTICE</emphasis> Scheduled expiration
nb-NO: <emphasis>I PRAKSIS</emphasis> Planlagt utløp

en: The expiration rules are not used by <command>dirvish-expire</command> to do its job. In reality, the expiration rules are applied when creating a new backup copy to define the expiration date associated with that copy. <command>dirvish-expire</command> simply peruses the stored copies and deletes those for which the expiration date has passed.
nb-NO: Utløpsreglene blir ikke brukt av <command>dirvish-expire</command> for å gjøre jobben sin. I realiteten blir utløpsregler brukt når du oppretter en ny sikkerhetskopi for å definere den utløpsdatoen som er knyttet til denne kopien. <command>dirvish-expire</command> leser ganske enkelt igjennom de lagrede kopiene, og sletter dem om utløpsdatoen har passert.

en: The <filename>/backup/root/dirvish/default.conf</filename> file
nb-NO: Filen <filename>/backup/root/dirvish/default.conf</filename>

en: The above example specifies the set of files to back up: these are files on the machine <emphasis>rivendell.falcot.com</emphasis> (for local data backup, simply specify the name of the local machine as indicated by <command>hostname</command>), especially those in the root tree (<literal>tree: /</literal>), except those listed in <literal>exclude</literal>. The backup will be limited to the contents of one filesystem (<literal>xdev: 1</literal>). It will not include files from other mount points. An index of saved files will be generated (<literal>index: gzip</literal>), and the image will be named according to the current date (<literal>image-default: %Y%m%d</literal>).
nb-NO: Eksempelet ovenfor spesifiserer settet med filer som skal sikkerhetskopieres: Dette er filer på maskinen <emphasis>rivendell.falcot.com</emphasis> (for lokal sikkerhetskopiering av data, ganske enkelt angi navnet på den lokale maskinen som angitt av <command>hostname</command>), særlig de i rot-treet (<literal>tree: /</literal>), untatt de som er listet i <literal>exclude</literal>. Sikkerhetskopien vil være avgrenset til innholdet i ett filsystem (<literal>xdev: 1</literal>). Den vil ikke inkludere filer fra andre monteringspunkter. En indeks over lagrede filer vil generes (<literal>index: gzip</literal>), og bildet blir navngitt med dagens dato (<literal>image-default: %Y%m%d</literal>).

en: <emphasis>IN PRACTICE</emphasis> Remote backup over SSH
nb-NO: <emphasis>I PRAKSIS</emphasis> Ekstern sikkerhetskopiering via SSH

en: When dirvish needs to save data to a remote machine, it will use <command>ssh</command> to connect to it, and will start <command>rsync</command> as a server. This requires the root user to be able to automatically connect to it. The use of an SSH authentication key allows precisely that (see <xref linkend="sect.ssh-key-based-auth" />).
nb-NO: Når dirvish trenger å lagre data på en ekstern maskin, vil den bruke <command>ssh</command> for å koble seg til den, og vil starte <command>rsync</command> som en tjener. Dette krever at rotbrukeren automatisk kan koble seg til den. Å bruke en SSH-autentiseringsnøkkel tillater nettopp dette (se <xref linkend="sect.ssh-key-based-auth" />).

en: Restoring Machines without Backups
nb-NO: Å gjenopprette maskiner uten sikkerhetskopier

en: The Falcot Corp administrators are aware of the limits in their backup policy. Since they can't protect the backup server as well as a tape in a fireproof safe, they have installed it in a separate room so that a disaster such as a fire in the server room won't destroy backups along with everything else. Furthermore, they do an incremental backup on DVD-ROM once per week — only files that have been modified since the last backup are included.
nb-NO: Falcot Corp administratorer er klar over begrensningene i sin sikkerhetskopi-politikk. Siden de ikke kan beskytte sikkerhetskopi-tjeneren samt et bånd (tape) i en brannsikker safe, har de installert det i et eget rom, slik at hendelser, for eksempel en brann i tjenerrommet, ikke ødelegger sikkerhetskopier sammen med alt annet. Videre lager de en trinnvis sikkerhetskopiering på DVD-ROM en gang pr. uke - kun de filer som er endret siden siste sikkerhetskopiering er inkludert.

en: <emphasis>GOING FURTHER</emphasis> Backing up SQL and LDAP services
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Sikkerhetskopiere SQL- og LDAP-tjenester

en: Many services (such as SQL or LDAP databases) cannot be backed up by simply copying their files (unless they are properly interrupted during creation of the backups, which is frequently problematic, since they are intended to be available at all times). As such, it is necessary to use an “export” mechanism to create a “data dump” that can be safely backed up. These are often quite large, but they compress well. To reduce the storage space required, you will only store a complete text file per week, and a <command>diff</command> each day, which is created with a command of the type <command>diff <replaceable>file_from_yesterday</replaceable> <replaceable>file_from_today</replaceable></command>. The <command>xdelta</command> program produces incremental differences from binary dumps.
nb-NO: Mange tjenester (som for eksempel SQL- eller LDAP-databaser) kan ikke sikkerhetskopieres bare ved å kopiere filene deres (med mindre de er riktig avbrutt når sikkerhetskopiene lages, noe som ofte er problematisk, siden de er ment å være tilgjengelig til enhver tid). Dermed er det nødvendig å bruke en «eksport»-mekanisme for å lage en «data dump» som trygt kan sikkerhetskopieres. Disse er ofte ganske store, men de komprimeres godt. For å redusere plassbehovet som trengs kan du bare lagre komplett tekstfil per uke, og en <command>diff</command> hver dag, som lages med en kommando av typen <command>diff <replaceable>gårsdagens_fil</replaceable> <replaceable>dagens_fil</replaceable></command>. Programmet <command>xdelta</command> lager økende forskjeller fra binære dumper.

en: <emphasis>CULTURE</emphasis> <emphasis>TAR</emphasis>, the standard for tape backups
nb-NO: <emphasis>KULTUR</emphasis> <emphasis>TAR</emphasis>, standarden for sikkerhetskopiering på tape (bånd)

en: <primary>backup</primary><secondary>on tape</secondary>
nb-NO: <primary>sikkerhetskopiering</primary><secondary>på tape</secondary>

en: <primary>tape, backup</primary>
nb-NO: <primary>tape, sikkerhetskopiering</primary>

en: Historically, the simplest means of making a backup on Unix was to store a <emphasis>TAR</emphasis> archive on a tape. The <command>tar</command> command even got its name from “Tape ARchive”.
nb-NO: De enkleste måtene for å lage en sikkerhetskopi på Unix var, historisk sett, å lagre et <emphasis>TAR</emphasis>-arkiv på et bånd. Kommandoen <command>tar</command> fikk til og med sitt navn fra «Tape ARchive».

en: Hot Plugging: <emphasis>hotplug</emphasis>
nb-NO: Varm tilkobling: <emphasis>hotplug</emphasis>

en: Introduction
nb-NO: Introduksjon

en: <primary>SATA</primary>
nb-NO: <primary>S-ATA</primary>

en: The kernel has a database that associates each device ID with the required driver. This database is used during boot to load all the drivers for the peripheral devices detected on the different buses, but also when an additional hotplug device is connected. Once the device is ready for use, a message is sent to <command>udevd</command> so it will be able to create the corresponding entry in <filename>/dev/</filename>.
nb-NO: Kjernen har en database som knytter hver enhets-ID med den nødvendige driveren. Denne databasen brukes under oppstart for å laste alle driverne til eksterne enheter som oppdages på forskjellige busser, men også når en ekstra varmtilkoblingsenhet blir koblet til. Når enheten er klar til bruk, sendes en melding til <command>udevd</command> slik at den kan lage den tilsvarende oppføringen i <filename>/dev/</filename>.

en: The Naming Problem
nb-NO: Navneproblemet

en: Before the appearance of hotplug connections, it was easy to assign a fixed name to a device. It was based simply on the position of the devices on their respective bus. But this is not possible when such devices can come and go on the bus. The typical case is the use of a digital camera and a USB key, both of which appear to the computer as disk drives. The first one connected may be <filename>/dev/sdb</filename> and the second <filename>/dev/sdc</filename> (with <filename>/dev/sda</filename> representing the computer's own hard drive). The device name is not fixed; it depends on the order in which devices are connected.
nb-NO: Før varm-tilkoblingene, var det enkelt å tilordne et fast navn til en enhet. Det var enkelt basert på enhetenes posisjonen på sine respektive busser. Men dette er ikke mulig når slike enheter kan komme og gå på bussen. Det typiske tilfellet er bruk av et digitalt kamera og en USB-minnepenn, som begge for datamaskinen ser ut som harddisker. Den første tilkoblede kan være <filename>/dev/sdb</filename> og den andre <filename>/dev/sdc</filename> (med <filename>/dev/sda</filename> som representerer datamaskinens egen harddisk). Enhetsnavnet er ikke fast; det er avhengig av rekkefølgen enheter er koblet til.

en: Additionally, more and more drivers use dynamic values for devices' major/minor numbers, which makes it impossible to have static entries for the given devices, since these essential characteristics may vary after a reboot.
nb-NO: I tillegg bruker flere og flere drivere dynamiske verdier for enhetenes store/små nummer, noe som gjør det umulig å ha statiske oppføringer for de gitte enhetene, siden deres grunnleggende egenskaper kan variere etter en omstart.

en: <emphasis>udev</emphasis> was created precisely to solve this problem.
nb-NO: <emphasis>udev</emphasis> ble laget nettopp for å løse dette problemet.

en: How <emphasis>udev</emphasis> Works
nb-NO: Hvordan <emphasis>udev</emphasis> virker

en: When <emphasis>udev</emphasis> is notified by the kernel of the appearance of a new device, it collects various information on the given device by consulting the corresponding entries in <filename>/sys/</filename>, especially those that uniquely identify it (MAC address for a network card, serial number for some USB devices, etc.).
nb-NO: Når <emphasis>udev</emphasis> varsles av kjernen når en ny enhet dukker opp, samler den ulike opplysninger om den gitte enheten ved å konsultere de tilsvarende oppføringene i <filename>/sys/</filename>, spesielt de som klart identifiserer den (MAC-adressen til et nettverkskort, serienummer for enkelte USB-enheter, etc.).

en: Armed with all of this information, <emphasis>udev</emphasis> then consults all of the rules contained in <filename>/etc/udev/rules.d/</filename> and <filename>/lib/udev/rules.d/</filename>. In this process it decides how to name the device, what symbolic links to create (to give it alternative names), and what commands to execute. All of these files are consulted, and the rules are all evaluated sequentially (except when a file uses “GOTO” directives). Thus, there may be several rules that correspond to a given event.
nb-NO: Bevæpnet med all denne informasjonen, <emphasis>udev</emphasis> konsulterer så alle reglene som ligger i <filename>/etc/udev/rules.d/</filename> og <filename>/lib/udev/rules.d/</filename>. I denne prosessen bestemmer den hvordan enheten skal navnes, hvilke symbolske lenker som skal lages (for å gi den alternative navn), og hvilke kommandoer som skal kjøres. Alle disse filene er konsultert , og reglene er alle vurdert sekvensielt (bortsett fra når en fil bruker «GOTO»-direktiver). Således kan det være flere regler som svarer til en gitt hendelse.

en: The syntax of rules files is quite simple: each row contains selection criteria and variable assignments. The former are used to select events for which there is a need to react, and the latter defines the action to take. They are all simply separated with commas, and the operator implicitly differentiates between a selection criterion (with comparison operators, such as <literal>==</literal> or <literal>!=</literal>) or an assignment directive (with operators such as <literal>=</literal>, <literal>+=</literal> or <literal>:=</literal>).
nb-NO: Regelfilenes syntaks er ganske enkel: Hver rad inneholder utvalgskriterier og variable oppdrag. Den første er brukt til å velge hendelser der det er behov for å reagere, og sistnevnte definerer handlingen som skal utføres. De er alle enkelt atskilt med komma, og operatøren skiller implisitt mellom et utvalgskriterium (med sammenligningsoperatorer, for eksempel <literal>==</literal>, eller <literal>!=</literal>), eller et oppdragsdirektiv (med operatorer som <literal>=</literal>, <literal>+=</literal> eller <literal>:=</literal>).

en: Comparison operators are used on the following variables:
nb-NO: Sammenligningsoperatorer brukes på følgende variabler:

en: <literal>KERNEL</literal>: the name that the kernel assigns to the device;
nb-NO: <literal>KJERNE</literal>: navnet som kjernen tilordner til enheten;

en: <literal>ACTION</literal>: the action corresponding to the event (“add” when a device has been added, “remove” when it has been removed);
nb-NO: <literal>ACTION</literal>: handlingen som tilsvarer hendelsen («add» når en enhet er lagt til, «remove» når den er fjernet);

en: <literal>DEVPATH</literal>: the path of the device's <filename>/sys/</filename> entry;
nb-NO: <literal>DEVPATH</literal>: Stien til enhetens <filename>/sys/</filename> inngang;

en: <literal>SUBSYSTEM</literal>: the kernel subsystem which generated the request (there are many, but a few examples are “usb”, “ide”, “net”, “firmware”, etc.);
nb-NO: <literal>SUBSYSTEM</literal>: kjerne-delsystemet som genererer forespørselen (det er mange, men noen eksempler er «usb»,«ide», «net», «firmware», etc.);

en: <literal>ATTR{<replaceable>attribute</replaceable>}</literal>: file contents of the <replaceable>attribute</replaceable> file in the <filename>/sys/<replaceable>$devpath</replaceable>/</filename> directory of the device. This is where you find the MAC address and other bus specific identifiers;
nb-NO: <literal>ATTR{<replaceable>attributt (egenskap)</replaceable>}</literal>: filinnholdet til <replaceable>attributt</replaceable>-filen i <filename>/sys/<replaceable>$devpath</replaceable>/</filename>-mappen til enheten. Det er her du finner MAC-adressen og andre buss-spesifikke identifikatorer;

en: <literal>KERNELS</literal>, <literal>SUBSYSTEMS</literal> and <literal>ATTRS{<replaceable>attributes</replaceable>}</literal> are variations that will try to match the different options on one of the parent devices of the current device;
nb-NO: <literal>KERNELS</literal>, <literal>SUBSYSTEMS</literal> og <literal>ATTRS{<replaceable>attributter</replaceable>}</literal> er variasjoner som vil prøve å treffe de ulike valgene hos en av de overordnede enhetene til den aktuelle enheten;

en: <literal>PROGRAM</literal>: delegates the test to the indicated program (true if it returns 0, false if not). The content of the program's standard output is stored so that it can be reused by the <literal>RESULT</literal> test;
nb-NO: <literal>PROGRAM</literal>: delegerer testen til det angitte programmet (sant hvis den returnerer 0, falsk hvis ikke). Innholdet av programmmets standard resultat blir lagret slik at det kan brukes om igjen av <literal>RESULT</literal>-testen;

en: <literal>RESULT</literal>: execute tests on the standard output stored during the last call to <literal>PROGRAM</literal>.
nb-NO: <literal>RESULT</literal>: utfører tester på standardresultatet lagret under siste kontakt til <literal>PROGRAM</literal>.

en: The right operands can use pattern expressions to match several values at the same time. For instance, <literal>*</literal> matches any string (even an empty one); <literal>?</literal> matches any character, and <literal>[]</literal> matches the set of characters listed between the square brackets (or the opposite thereof if the first character is an exclamation point, and contiguous ranges of characters are indicated like <literal>a-z</literal>).
nb-NO: De riktige operander kan bruke mønsteruttrykk for å finne flere verdier som passer samtidig. For eksempel, <literal>*</literal> matcher alle strenger (selv en tom en); <literal>?</literal> treffer hvilken som helst tegn, og <literal>[]</literal> matcher settet med tegn som er listet mellom hakeparenteser (eller det motsatte hvis det første tegnet er et utropstegn, og sammenhengende rekker med tegn er angitt som <literal>a-z</literal>).

en: Regarding the assignment operators, <literal>=</literal> assigns a value (and replaces the current value); in the case of a list, it is emptied and contains only the value assigned. <literal>:=</literal> does the same, but prevents later changes to the same variable. As for <literal>+=</literal>, it adds an item to a list. The following variables can be changed:
nb-NO: Når det gjelder tildelingsoperatørene, <literal>=</literal> tildeler en verdi (og erstatter gjeldende verdi); i tilfelle av en liste, blir den tømt, og inneholder bare den tildelte verdien. <literal>:=</literal> gjør det samme, men hindrer senere endringer i samme variabel. Når det gjelder <literal>+=</literal>, legger den til et element i en liste. Følgende variabler kan endres:

en: <literal>NAME</literal>: the device filename to be created in <filename>/dev/</filename>. Only the first assignment counts; the others are ignored;
nb-NO: <literal>NAME</literal>: filnavnet til enheten som skal opprettes i <filename>/dev/</filename>. Bare den første oppgaven teller; de andre blir ignorert;

en: <literal>SYMLINK</literal>: the list of symbolic links that will point to the same device;
nb-NO: <literal>SYMLINK</literal>: listen med symbolske lenker som vil peke til den samme enheten;

en: <literal>OWNER</literal>, <literal>GROUP</literal> and <literal>MODE</literal> define the user and group that owns the device, as well as the associated permission;
nb-NO: <literal>OWNER</literal>, <literal>GROUP</literal> og <literal>MODE</literal> definerer brukeren og gruppen som eier enheten, samt tilhørende tillatelse;

en: <literal>RUN</literal>: the list of programs to execute in response to this event.
nb-NO: <literal>RUN</literal>: listen over programmer som må kjøres som reaksjon på denne hendelsen.

en: The values assigned to these variables may use a number of substitutions:
nb-NO: Verdiene tilordnet disse variablene kan bruke en rekke erstatninger:

en: <literal>$kernel</literal> or <literal>%k</literal>: equivalent to <literal>KERNEL</literal>;
nb-NO: <literal>$kernel</literal> eller <literal>%k</literal>: som tilsvarer <literal>KERNEL</literal>;

en: <literal>$number</literal> or <literal>%n</literal>: the order number of the device, for example, for <literal>sda3</literal>, it would be “3”;
nb-NO: <literal>$number</literal> eller <literal>%n</literal>: rekkefølgenummeret til enheten, for eksempel for <literal>sda3</literal>, ville det være «3»;

en: <literal>$devpath</literal> or <literal>%p</literal>: equivalent to <literal>DEVPATH</literal>;
nb-NO: <literal>$devpath</literal> eller <literal>%p</literal>: som tilsvarerer <literal>DEVPATH</literal>;

en: <literal>$attr{<replaceable>attribute</replaceable>}</literal> or <literal>%s{<replaceable>attribute</replaceable>}</literal>: equivalent to <literal>ATTRS{<replaceable>attribute</replaceable>}</literal>;
nb-NO: <literal>$attr{<replaceable>attributt</replaceable>}</literal> eller <literal>%s{<replaceable>attributt</replaceable>}</literal>: som tilsvarer <literal>ATTRS{<replaceable>attributt</replaceable>}</literal>;

en: <literal>$major</literal> or <literal>%M</literal>: the kernel major number of the device;
nb-NO: <literal>$major</literal> eller <literal>%M</literal>: hovednummeret for enheten i kjernen;

en: <literal>$minor</literal> or <literal>%m</literal>: the kernel minor number of the device;
nb-NO: <literal>$minor</literal> eller <literal>%m</literal>: undernummer for enheten i kjernen;

en: <literal>$result</literal> or <literal>%c</literal>: the string output by the last program invoked by <literal>PROGRAM</literal>;
nb-NO: <literal>$result</literal> eller <literal>%c</literal>: resultatstrengen fra det siste programmet aktivert av <literal>PROGRAM</literal>;

en: and, finally, <literal>%%</literal> and <literal>$$</literal> for the percent and dollar sign, respectively.
nb-NO: og, til slutt, <literal>%%</literal> og <literal>$$</literal> for henholdsvis prosent og dollartegnet.

en: A concrete example
nb-NO: Et konkret eksempel

en: Let us consider the case of a simple USB key and try to assign it a fixed name. First, you must find the elements that will identify it in a unique manner. For this, plug it in and run <command>udevadm info -a -n /dev/sdc</command> (replacing <replaceable>/dev/sdc</replaceable> with the actual name assigned to the key).
nb-NO: La oss vurdere tillfellet med en enkel USB-minnepenn, og prøve å tilordne et fast navn til den. Først må du finne de elementene som unikt vil identifisere den. For å få til dette plugg den inn og kjør <command>udevadm info -a -n /dev/sdc</command> (for å erstatte <replaceable>/dev/sdc</replaceable> med det faktiske navnet minnepennen har).

en: To create a new rule, you can use tests on the device's variables, as well as those of one of the parent devices. The above case allows us to create two rules like these:
nb-NO: For å opprette en ny regel kan du bruke tester på enhetens variabler, så vel som de fra en av de overordnede enhetene. Det ovennevnte tilfellet tillater oss å lage to regler som disse:

en: Once these rules are set in a file, named for example <filename>/etc/udev/rules.d/010_local.rules</filename>, you can simply remove and reconnect the USB key. You can then see that <filename>/dev/usb_key/disk</filename> represents the disk associated with the USB key, and <filename>/dev/usb_key/part1</filename> is its first partition.
nb-NO: Når disse reglene er satt i en fil, som for eksempel er døpt <filename>/etc/udev/rules.d/010_local.rules</filename>, kan du enkelt fjerne og koble til USB-minnepennen. Deretter kan du se at <filename>/dev/usb_key/disk</filename> representerer disken knyttet til USB-minnepennen, og <filename>/dev/usb_key/part1</filename> er dens første partisjon.

en: <emphasis>GOING FURTHER</emphasis> Debugging <emphasis>udev</emphasis>'s configuration
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Feilsøking i oppsettet til <emphasis>udev</emphasis>

en: Like many daemons, <command>udevd</command> stores logs in <filename>/var/log/daemon.log</filename>. But it is not very verbose by default, and it is usually not enough to understand what is happening. The <command>udevadm control --log-priority=info</command> command increases the verbosity level and solves this problem. <command>udevadm control --log-priority=err</command> returns to the default verbosity level.
nb-NO: Som for mange bakgrunnsprosesser, lagrer <command>udevd</command> logger i <filename>/var/log/daemon.log</filename>. Men det er ikke veldig detaljert som standard, og det er som regel ikke nok til å forstå hva som skjer. Kommandoen <command>udevadm control --log-priority=info</command> øker detaljnivået, og løser dette problemet. <command>udevadm control --log-priority=err</command> returnerer til standard detaljnivå.

en: Power Management: Advanced Configuration and Power Interface (ACPI)
nb-NO: Strømstyring: Advanced Configuration and Power Interface (ACPI)

en: The topic of power management is often problematic. Indeed, properly suspending the computer requires that all the computer's device drivers know how to put them to standby, and that they properly reconfigure the devices upon waking. Unfortunately, there are still a few devices unable to sleep well under Linux, because their manufacturers have not provided the required specifications.
nb-NO: Emnet strømstyring er ofte problematisk. Faktisk, riktig hvilemodus for maskinen krever at alle datamaskinens enhetsdrivere vet hvordan de settes i ventemodus, og at de skal sette opp enhetene igjen ved oppvåkning. Dessverre er det fortsatt noen få enheter som ikke kan sove godt under Linux, fordi produsentene deres ikke har gitt de nødvendige spesifikasjonene.

en: <emphasis>BEWARE</emphasis> Graphics card and standby
nb-NO: <emphasis>PASS PÅ</emphasis> Grafikkort og ventemodus

en: The graphics card driver is often the culprit when standby doesn't work properly. In that case, it is a good idea to test the latest version of the X.org graphics server.
nb-NO: Grafikkortdriveren er ofte den skyldige når ventemodus ikke fungerer ordentlig. I så fall er det en god idé å teste den nyeste versjonen av X.org grafikktjener.

en: After this overview of basic services common to many Unix systems, we will focus on the environment of the administered machines: the network. Many services are required for the network to work properly. They will be discussed in the next chapter.
nb-NO: Etter denne oversikten over grunnleggende tjenester felles for mange Unix-systemer, vil vi fokusere på miljøet for de administrerte maskinene: Nettverket. Mange tjenester er nødvendige for at nettverket skal fungere ordentlig. De blir diskutert i neste kapittel.
