2. Debian Handbook
  3. 12_advanced-administration

Please sign in to see the alerts.
Project website https://debian-handbook.info/
Mailing list for translators debian-handbook-translators@lists.alioth.debian.org
Instructions for translators

https://debian-handbook.info/contribute/
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Translation license GNU General Public License v2.0 or later
Repository https://salsa.debian.org/hertzog/debian-handbook.git
Repository branch buster/master
Last remote commit Fix markup in the "Apache > Allow from" index entry c730f2d8
User avatar rhertzog authored 16 hours ago
Repository containing Weblate translations https://hosted.weblate.org/git/debian-handbook/12_advanced-administration/
Filemask*/12_advanced-administration.po
Number of strings 12,825
Number of words 495,350
Number of characters 3,674,025
Number of languages 25
Number of source strings 513
Number of source words 19,814
Number of source characters 146,961
User avatar pere

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

<primary>Logical Volume Manager</primary>
<primary>Logical Volume Manager ( logisk volumhåndtering)</primary>
12 hours ago
User avatar pere

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
på <filename>sdf</filename>- disken, en <filename>sdf1</filename>-partisjon, 4 GB; og en <filename>sdf2</filename>-partisjon, 5 GB.
13 hours ago
User avatar pere

Committed changes

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

Committed changes 13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
Med et raskt øyekast, inkludert filen for forhåndsutfylling i initrd, ser den ut som den mest interessante løsningen; men den er imidlertid sjelden brukt i praksis, fordi å generere et installasjons-initrd er ganske komplisert. De to andre løsninger er mye mer vanlige, spesielt siden oppstartsparametere gir en annen måte til å forhåndsutfylle de første spørsmålene på i installasjonsprosessen. Den vanlige måten å spare bryet med å skrive disse oppstartsparametere for hånd på hver installasjon, er å lagre dem inn i oppsettet for <command>isolinux</command> (i CD-ROM tilfellet eller <command>syslinux</command> (ved USB-pinne).
13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

Each of these solutions has its pros and cons: SystemImager works independently from any particular packaging system, which allows it to manage large sets of machines using several distinct Linux distributions. It also includes an update system that doesn't require a reinstallation, but this update system can only be reliable if the machines are not modified independently; in other words, the user must not update any software on their own, or install any other software. Similarly, security updates must not be automated, because they have to go through the centralized reference image maintained by SystemImager. This solution also requires the target machines to be homogeneous, otherwise many different images would have to be kept and managed (an i386 image won't fit on a powerpc machine, and so on).
Hver av disse løsningene har sine fordeler og ulemper: SystemImager fungerer uavhengig av et bestemt pakkesystem, som gjør det mulig å håndtere store sett med maskiner ved hjelp av flere forskjellige Linux-distribusjoner. Det inkluderer også et oppdateringssystem som ikke krever en reinstallasjon, men dette oppdateringssystemet kan bare være pålitelig hvis maskinene ikke endres hver for seg; med andre ord, brukeren må ikke oppdatere programvare på egen hånd, eller installere noen annen programvare. Tilsvarende sikkerhetsoppdateringer må ikke være automatisert, fordi de må gå gjennom det sentraliserte referansebildet som vedlikeholdes av SystemImager. Denne løsningen krever også at maskinene det gjelder er homogene, ellers må mange forskjellige bilder tas vare på og håndteres (et i386-bilde vil ikke passe på en PowerPC-maskin, og så videre).
13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
I tillegg til <emphasis role="pkg">bridge-utils</emphasis>, krever dette «rike» oppsettet <emphasis role="pkg">vde2</emphasis>-pakken; <filename>/etc/network/interfaces</filename>-filen blir da:
13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

These features can be combined to isolate a whole process family starting from the <command>init</command> process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: <emphasis>LinuX Containers</emphasis>), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).
Disse egenskapene kan kombineres for å isolere en hel prosessfamilie som starter fra <command>init</command>-prossessen, og det resulterende settet ser mye ut som en virtuell maskin. Det offisielle navnet på et slikt oppsett er en «beholder» (derav LXC-forkortelsen: <emphasis>LinuX Containers</emphasis>), men en ganske viktig forskjell til «ekte» virtuelle maskiner, som leveres av Xen eller KVM, er at det ikke er noen ekstra kjerne; beholderen bruker den samme kjernen som vertssystemet. Dette har både fordeler og ulemper: Fordelene inkluderer utmerket ytelse grunnet total mangel på ekstrabelastning, og det faktum at kjernen har full oversikt over alle prosesser som kjører på systemet, slik at planleggingen kan være mer effektiv enn hvis to uavhengige kjerner skulle planlegge ulike oppgavesett. Den største blant ulempene er at det er umulig å kjøre en annen kjerne i en beholder (enten en annen Linux-versjon, eller et annet operativsystem i det hele tatt).
13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

The rationale for the second split (<filename>md1</filename> vs. <filename>md2</filename>) is less clear-cut, and more related to acknowledging that the future is uncertain. When the workstation is first assembled, the exact storage requirements are not necessarily known with perfect precision; they can also evolve over time. In our case, we can't know in advance the actual storage space requirements for video rushes and complete video clips. If one particular clip needs a very large amount of rushes, and the VG dedicated to redundant data is less than halfway full, we can re-use some of its unneeded space. We can remove one of the physical volumes, say <filename>md2</filename>, from <filename>vg_raid</filename> and either assign it to <filename>vg_bulk</filename> directly (if the expected duration of the operation is short enough that we can live with the temporary drop in performance), or undo the RAID setup on <filename>md2</filename> and integrate its components <filename>sda6</filename> and <filename>sdc6</filename> into the bulk VG (which grows by 200 GB instead of 100 GB); the <filename>lv_rushes</filename> logical volume can then be grown according to requirements.
Begrunnelsen for den andre delingen (<filename>md1</filename> mot <filename>md2</filename>) er mindre entydig, og mer knyttet til erkjennelsen av at fremtiden er usikker. Når arbeidsstasjonen først er montert, er de eksakte kravene til oppbevaring ikke nødvendigvis kjent med perfekt presisjon. De kan også utvikle seg over tid. I vårt tilfelle kan vi ikke på forhånd vite det faktiske lagringsbehovet for video-opptak og komplette videoklipp. Hvis et bestemt klipp har en meget stor mengde uredigerte opptak, og VG-en øremerket til ledige data er mindre enn halvveis full, kan vi gjenbruke noe av den plassen som ikke trengs. Vi kan fjerne et av de fysiske volumene, la oss si <filename>md2</filename>, fra <filename>vg_raid</filename>, og enten knytte det til <filename>vg_bulk</filename> direkte (hvis den forventede varigheten av operasjonen er kort nok til at vi kan leve med midlertidig fall i ytelsen), eller sette tilbake RAID-oppsettet på <filename>md2</filename>, og integrere komponentene dens, <filename>sda6</filename>, og <filename>sdc6</filename>, i den store VG-en (som ekspanderer til 200 GB i stedet for 100 GB). Det logiske volumet <filename>lv_rushes</filename> kan så ekspandere i tråd med det som kreves.
13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited videoclips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.
La oss ta et konkret eksempel: PR-avdelingen på Falcot Corp trenger en arbeidsstasjon for videoredigering, men avdelingens budsjett tillater ikke investere i dyr maskinvare fra bunnen av. Det er bestemt at maskinvaren som er spesifikk for det grafiske arbeidets art (skjerm og skjermkort) skal prioriteres, og at en skal fortsette med felles maskinvare for lagring. Men som kjent har digital video noen særegne krav til lagringen sin, datamengden er stor og gjennomstrømmingshastigheten for lesing og skriving er viktig for systemets generelle ytelse (for eksempel mer enn typisk aksesstid). Disse begrensningene må imøtekommes med vanlig maskinvare, i dette tilfellet to 300 GB SATA-harddisker. Systemdata må også gjøres motstandsdyktig mot maskinvarefeil, det samme gjelder noe brukerdata. Ferdigredigerte videoklipp må være trygge, men for videoer som venter på redigering er det mindre kritisk, siden de fortsatt er på videobånd.
13 hours ago
User avatar oeyrvin

Translation changed

Debian Handbook / 12_advanced-administration — Norwegian Bokmål

If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (<indexterm><primary>SSD</primary></indexterm><emphasis>solid-state drives</emphasis> or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.
Hvis input/output-hastighet er viktig, spesielt i form av aksesstid, kan det å bruke LVM og/eller RAID i en av de mange kombinasjonene ha en viss innvirkning på ytelser, og dette kan påvirke beslutninger om hvilken som skal velges. Men disse forskjellene i ytelse er veldig små, og vil bare være målbare i noen brukstilfeller. Hvis ytelsen betyr noe, er det størst gevinst ved å bruke ikke-roterende lagringsmedier (<indexterm><primary>SSD</primary></indexterm><emphasis>solid-state drives</emphasis>, eller SSDs). Kostnaden deres pr. megabyte er høyere enn for standard harddisker, kapasiteten deres er vanligvis mindre, men de gir utmerkede resultater for tilfeldig aksess. Hvis bruksmønster inneholder mange input/output-operasjoner spredt rundt i filsystemet, for eksempel for databaser der komplekse spørringer blir kjørt rutinemessig, så oppveier fordelen av å kjøre dem på en SSD langt hva som kan oppnås ved å velge LVM over RAID eller omvendt. I slike situasjoner bør valget bestemmes av andre hensyn enn ren fart, siden ytelsesaspektet lettest håndteres ved å bruke SSD.
13 hours ago
Browse all component changes

Daily activity

Daily activity

Weekly activity

Weekly activity