Re: Om debian på desktoppen
On Tue, 7 May 2024, Flemming Bjerke wrote: Den 06.05.2024 kl. 15.18 skrev Povl Ole Haarlev Olsen: Har du prøvet Debian backports? Fordi jeg ikke orker at styre det: It is recommended to pick out single backports which fit your needs, and not to use all backports available. https://wiki.debian.org/Backports Jeg er ikke sikker på, at jeg ved hvorfor du mener det er besværligt at styre. Du installer en pakke som normalt. ("dia" er, som sagt, ikke i backports, men da du ikke har nævnt andre pakker, bruger jeg alligevel den som eksempel.) Du opdager, at "dia" fra stable af den ene eller anden grund ikke er "god nok". Din løsning har været noget med at køre dia fra en Kubuntu chroot. Med backports beder du i stedet pakkesystemet om at installere dia fra backports. Enten vha. apt install dia/bookworm-backports (hvor du kun får "dia" fra backports, men ikke eventuelle dependencies) eller vha. apt -t bookworm-backports install dia (hvor både "dia" og eventuelle dependencies bliver installeret fra backports) Og... Det er vist det. Nyeste Q2OS er baseret på bookworm med nogle systemændringer. ls /etc/apt/sources.list.d/ 10_q4os.list 20_debian.list 30_debian_backports.list (backports er ikke aktiveret) Hint: Hvis man vil disable en fil i /etc/apt/sources.list.d/ uden at pille i selve filen, kan man nøjes med at rename filen, så den ikke hedder *.list, f.eks. hedder nogle af mine *.list.disabled chroot /a2 mount /dev/sda4 /home Hvad er grunden til, at du ikke bind-mounter /home? Det er vel også det rigtigste at bruge bind. Men gør det nogen forskel? Med bind-mount burde der kun være een version af filesystem koden i brug og derfor også kun een ting, der snakker med /dev/sda4. Mens der med et "rigtigt" mount kunne være to versioner filesystem koden i brug, en for /home og en for /a2/home, og derfor to ting, der prøver at snakke med /dev/sda4 samtidig. Jeg har ikke checket, om det kunne give problemer. Det var lettere bare at bruge et bind-mount og slippe for at tænke over den slags ting. chroot /a2 #Her kan man udføre alle mulige kommandoer. Skriptet venter til man kører: exit. #chroot --userspec=flem:flem /a2 (fungerer ikke - forstår ikke hvorfor) Hmm, hvorfor har jeg ikke hørt om --userspec før?! man chroot Ja, jeg er godt klar over, at det selvfølgelig står i man siden. Men hvem læser man sider, når ens script virker "fint"? :-) Og nu kan mit skript forenkles ganske meget: #!/bin/bash mount --bind /home /a2/home bash -c "HOME=/home/flem chroot --userspec=flem:flem /a2 $1" Med "$@" i stedet for "$1" burde du også kunne give din kommando argumenter, f.eks. bede dia om at åbne en specifik fil. Det virker ikke som om man behøver mount --bind /sys osv. Faktisk fik jeg lidt problemer når jeg gjorde det fordi alt i /dev/pts/ forsvandt. Hvorfor fatter jeg ikke, men det har nok noget at gøre med: While ‘chroot’ is a powerful tool, it’s not a security measure by itself. Processes that are running as root can break out of the chroot jail. https://hopeness.medium.com/master-the-linux-chroot-command-a-comprehensive-guide-f2026f913726 Ok, det er ikke noget, jeg selv har oplevet, men det er efterhånden også et godt stykke tid siden jeg sidst brugte chroot, så måske er noget blev ændret. Men jeg skal nok ikke opdatere kubuntu via chroot ... Risikerer jeg ikke at der kommer ged i kernen og boot ... osv.? Jeg har ikke haft /boot mountet i mine chroots, så den slags har jeg aldrig tænkt nærmere over. Hvis et chroot ville ændrer i hvad det troede var /boot, så var det i virkelighed f.eks. /opt/wheezy/boot og ikke det rigtige /boot. -- Povl Ole
Re: Om debian på desktoppen
On Mon, 6 May 2024, Flemming Bjerke wrote: Jeg har adskillige gange opgivet debian på desktoppen fordi jeg ustandselig fik problemer med alt muligt der ikke rigtig virkede, bl.a. programmer som ikke fungerede og ikke kunne opdateres pga. debians restriktioner på hvornår programmer kunne blive stable. (Jeg har dog ikke prøvet bookworm af.) Jeg har så valgt at køre med kubuntu i årevis. Har du prøvet Debian backports? "dia" er, så vidt jeg kan se, ikke i backports, men måske kunne det bruges med nogle af de andre programmer, hvor du ønsker en nyere version. Jeg er meget tilfreds med at køre et debian system (sources er primært debian stable), for jeg har normalt ikke brug for de nyeste versioner af forskelligt software. Derimod er stabiliteten vigtig for mig. Men ind i mellem får man brug for en nyere version af et program. F.eks. er bookworm's version af dia håbløst buggy. Så fandt jeg på at chroot til min kubuntu som ligger (passivt) Hvordan ved du, at bookworms dia er buggy, hvis du ikke har prøvet bookworm? på den anden partion. Og vupti fungerede dia igen. Jeg lavede følgende skript: --- #!/bin/bash mount --bind /dev /a2/dev mount --bind /dev/pts /a2/dev/pts mount --bind /proc /a2/proc mount --bind /sys /a2/sys chroot /a2 mount /dev/sda4 /home Hvad er grunden til, at du ikke bind-mounter /home? chroot /a2 #Her kan man udføre alle mulige kommandoer. Skriptet venter til man kører: exit. #chroot --userspec=flem:flem /a2 (fungerer ikke - forstår ikke hvorfor) Hmm, hvorfor har jeg ikke hørt om --userspec før?! Hvilken fejlbesked får du? chroot /a2 umount /dev/sda4 umount /a2/sys umount /a2/proc umount /a2/dev/pts umount /a2/dev echo 'a2 er nu forladt' (Mit kubuntu ligger på /a2 som monteres automatisk ved start.) Nu kan jeg starte f.eks. kubuntus dia (og libreoffice) fra en terminal, og hvis jeg gør det med et & efter, fungerer fungerer programmet videre selv efter exit fra chroot. Hvad synes I om min løsning? Jeg har haft noget i samme stil (med /home bind-mounted) for at kunne bruge en ældre version af bl.a. xpra. Jeg havde alle mine bind-mounts i /etc/fstab og en desktop launcher, der "run in terminal" kørte su -c "chroot /opt/wheezy /bin/su - stderr -c /usr/bin/xfce4-terminal & bg" (Med --userspec ville den linie sikkert kunne skæres kraftigt ned.) Launcher'en startede en terminal og alt startet i den terminal blev kørte fra en wheezy installation, jeg havde debootstrap'et i /opt/wheezy. Det virkede fint til mit formål. Det er selvfølgelig ikke uproblematisk at køre to forskellige systemer på samme home-partition, men hvis man ikke bruger samme programmer på dem, burde det vel ikke skabe de store problemer? Hvis programmer opførte sig nogenlunde pænt, ville det heller ikke være noget problem, at køre de samme programmer på samme homedir. Da jeg var studerende var vores homedirs mountet på Linux, HP-UX, IRIX, Solaris, ... og jeg tænkte ikke ret meget over, om jeg kunne tillade mig, at starte et program på en given platform eller ej. Men jeg ved godt, at der er nogle programmer, der meget gerne vil lave en "upgrade" af deres config i ~/.config uden at tænke over, at man måske deler sit homedir mellem mange forskellige installationer. Det er eet af problemer ved, at nogen ikke længere ser Linux som et multi-user system i UNIX-familien. -- Povl Ole
Re: Backup ... men hvordan
On Mon, 19 Dec 2022, Flemming Bjerke wrote: Mit spørgsmål var i virkeligheden: Hvor længe gemmer I backups, efter hvilket skema? Og hvor tit laver I full backup, og hvor tit incrementel? Det kommer nok helt an på hvad det er for nogle data og hvilke regler, man er underlagt. Er der ikke noget med, at firmaer skal gemme nogle regneskabsdata 5 eller 10 år tilbage? Af nogle filesystems på nogle af mine maskiner, laver jeg en daglig backup med mit backup script. Af /home på nogle af mine maskiner, laver jeg en backup hver time. Jeg bruger rsync --link-dest, så jeg ved ikke helt om du vil kalde det en full backup eller incremental. Hver backup dir har alle data fra det givne tidspunkt, men pladsen per backup dir (undtagen den første backup) svarer til en incremental backup. Det er forskelligt hvor længe jeg gemmer data. Filesystemer, der næsten ikke ændrer sig, koster ikke ret meget mere plads, når hver backup er med --link-dest til forrige backup, så der kan jeg uden store problemer have backups liggende i et år eller mere. Mere aktive filesystemer, hvor filer tit ændrer sig eller bliver flyttet, koster lidt mere plads, så det er sværere at retfærdigøre pladsforbruget. Som et par modspørgsmål til dit spørgsmål er: Hvilken type data? Er der særlig regler for de data, som du skal overholde? Hvor tit er der nye/ændrede data? Hvor meget/lidt plads vil du bruge? -- Povl Ole
Re: Backup ... men hvordan
On Mon, 19 Dec 2022, Flemming Bjerke wrote: Den 19.12.2022 kl. 05.38 skrev Povl Ole Haarlev Olsen: On Mon, 19 Dec 2022, Flemming Bjerke wrote: Men jeg glemmer aldrig da jeg havde brugt srv til backup, og så pludselig kunne jeg ikke tilgå de gamle versioner ... og hvorfor ... pga. en eller anden kendt bug som ingen havde gjort noget ved. Jeg ville aldrig turde lægge Har du lyst til at fortælle hvilket program, du brugte og hvad bug'en var, så vi andre lettere kan checke, om vi måske også har et problem? Undskyld, det var CVS, og det var dengang git begyndte at blive rigtig udbredt ... altså 10-15 år siden ... så det er historie, og jeg husker overhovedet ikke hvad buggen gik ud på. Blot at den var beskrevet, og at jeg ikke fandt nogen løsninger på nettet, men derimod andre som heller ikke havde fundet nogen løsninger. Interessant, især fordi jeg stadig bruge CVS. min endelige backup i en krypteret fil som kun et program kan tilgå, og hvis Det lyder meget som noget hjemmerullet kryptering. Man skal selvfølgelig bruge en eller anden standard, som nogle kloge mennesker har tænkt længe over og som findes i mere end een implementation. Hjemmerullet kryptering ... nej, så selvovervurderende er jeg alligevel ikke ;-) Og, det må være rigtigt at hvis man skal have alt liggende krypteret så må man have mindst 2 uafhængige implementationer. Jeg mente ikke nødvendigvis hjemmerullet af dig, men af dem, der har lavet det een program, som kan tilgå backup'en. jeg mistede nøglen ... Jeg får ondt i maven ved tanken. Jeg tænker ikke at jeg afskaffer mine to fysiske bakop-harddiske som ikke er koblet på min computer til daglig, og hvor intet er krypteret. Du kunne gemme nøglen på dine to backup harddiske. Medmindre du altså regner med at smide alle tre kopier væk samtidig. Men du kan jo også skrive nøglen på et papir, som kan ligge i din bankboks. Eller 2/3 af din nøgle til tre af dine venner, så ingen af dem kan tilgå backup'en alene. Eller... Der er mange løsninger for at undgå, at man mister sin key. Tak, for gode ideer. Hvis du vil kigge nærmere på det der med en splittet key, hvor der skal X dele til at lave en hel key, så tag et kig på "" pakken. Umiddelbart virker det som om du har tænkt dig, at lave en kopi af filesystemet, hvor mariadb har sine data liggende. Hvis du gør det mens mariadb kører, skal du være opmærksom på, at du måske ikke kan bruge din backup til noget, f.eks. fordi mariadb kan have ting cachet, som endnu ikke er lagt ud i filerne eller fordi der går noget tid mens du kopiere filerne og de første filer derfor kan nå at ændre sig, mens du stadig er i gang med at kopiere de sidste filer. Som beskrevet tidligere, havde jeg tænkt at bruge maria-backup som har alt muligt indbygget omkring at databsen kører, osv. Problemet er at man for hver incrementel backup selv skal lave en ny mappe hvori maria-backup kan lægge diverse filer og linke til den tidligere incrementelle mappe, som linker til forrige mappe, osv., osv., indtil en full-backup. Jeg kunne så ikke finde nogle bud på hvordan man på nettet byggede en klog bakop af mariadb på det grundlag. Der er vel en trade-off mellem simpel teknisk bakop og andre hensyn såsom praktisk anvendelighed og sårbarhed, eksemplificeret med at jeg ikke lige forestiller mig at nogen ville lave en kæde på 730 mapper med incrementel bakop af mariadb over 2 år. Men der tager jeg måske fejl? Jeg bruger, som sagt, ikke mariadb og kender derfor ikke maria-backup, men hvis den ikke selv understøtter det, så lyder det som du "bare" skal diff'e filerne fra dagens backup med filerne fra igår. De filer, der er ens skal så bare erstattes af hardlinks til gårdagens backup (som så igen kan være hardlinks til dem fra i forgårs osv.) Derefter kunne rsync -H --link-dest ${LAST_TIMESTAMP} ... være din ven. Problematikken gælder vel generelt. Vælger man f.eks. 2 års = 730 dages incrementel bakop med rdiff-bakop? Eller hvordan gør I andre som jo er professionelle? Ovenstående rsync kommando plus lidt flere options er en del af nogle af mine backup scripts. Den korte version af de scripts er noget a'la: [- Quote -] TIMESTAMP=$(date -u +%Y-%m-%d-T-%H-%M) BACKUP_ID=$1 shift SRC_DIR=$1 shift BACKUP_SERVER=$1 shift DEST_DIR=$1 shift BACKUP_LOG_DIR=/var/local/log mkdir -p ${BACKUP_LOG_DIR} LAST_TIMESTAMP_FILE=${BACKUP_LOG_DIR}/${BACKUP_ID}.timestamp if [ -e ${LAST_TIMESTAMP_FILE} ] then LAST_TIMESTAMP=$(cat ${LAST_TIMESTAMP_FILE}) LINK_DEST="--link-dest ${DEST_DIR}/${LAST_TIMESTAMP}" fi rsync \ -HPSavx \ ${LINK_DEST} \ ${SRC_DIR}/ \ ${BACKUP_SERVER}:${DEST_DIR}/${TIMESTAMP}/ \ >${BACKUP_LOG_DIR}/${BACKUP_ID}.${TIMESTAMP}.log 2>&1 echo ${TIMESTAMP} > ${LAST_TIMESTAMP_FILE} [- End quote -] Ovenstående forudsætter at den, der kører scriptet (root?) har en ssh-key, der kan logge ind på ${BACKU
Re: Backup ... men hvordan
On Mon, 19 Dec 2022, Flemming Bjerke wrote: Men jeg glemmer aldrig da jeg havde brugt srv til backup, og så pludselig kunne jeg ikke tilgå de gamle versioner ... og hvorfor ... pga. en eller anden kendt bug som ingen havde gjort noget ved. Jeg ville aldrig turde lægge Har du lyst til at fortælle hvilket program, du brugte og hvad bug'en var, så vi andre lettere kan checke, om vi måske også har et problem? min endelige backup i en krypteret fil som kun et program kan tilgå, og hvis Det lyder meget som noget hjemmerullet kryptering. Man skal selvfølgelig bruge en eller anden standard, som nogle kloge mennesker har tænkt længe over og som findes i mere end een implementation. jeg mistede nøglen ... Jeg får ondt i maven ved tanken. Jeg tænker ikke at jeg afskaffer mine to fysiske bakop-harddiske som ikke er koblet på min computer til daglig, og hvor intet er krypteret. Du kunne gemme nøglen på dine to backup harddiske. Medmindre du altså regner med at smide alle tre kopier væk samtidig. Men du kan jo også skrive nøglen på et papir, som kan ligge i din bankboks. Eller 2/3 af din nøgle til tre af dine venner, så ingen af dem kan tilgå backup'en alene. Eller... Der er mange løsninger for at undgå, at man mister sin key. Men det løser ikke mit problem med hvordan man bakker mariadb op. Hvad synes I om følgende løsning? 1. Hvert kvartal full backup. Slettes efter 5/4 år. 2. Hver måned incrementel bakop ift. seneste kvartals full backup. Slettes efter et år. 3. Hver uge incrementel bakop ift. seneste kvartals full backup, slettes efter 1½ måned. 4. Daglig incrementel bakup i forhold til seneste kvartals full backup. Slettes efter 10 dage. Grundlaget skulle være et lille simpelt skript i stil med vedhæftede. Umiddelbart virker det som om du har tænkt dig, at lave en kopi af filesystemet, hvor mariadb har sine data liggende. Hvis du gør det mens mariadb kører, skal du være opmærksom på, at du måske ikke kan bruge din backup til noget, f.eks. fordi mariadb kan have ting cachet, som endnu ikke er lagt ud i filerne eller fordi der går noget tid mens du kopiere filerne og de første filer derfor kan nå at ændre sig, mens du stadig er i gang med at kopiere de sidste filer. Jeg bruger ikke selv mariadb, men i f.eks. postgresql er der et tool til at lave backups af en database, der er i aktiv brug. Jeg regner med, at mariadb har et tool i samme stil. Det tool vil dog lave en full backup af din database, ikke incremental. TL;DR: Enten stopper du databasen hverken du laver en backup eller du laver en fuld backup hver gang. Eller du har en måske ubrugelig backup... -- Povl Ole
Re: Fanget i DNS
On Thu, 3 Nov 2022, Flemming Bjerke wrote: Den 03.11.2022 kl. 11.29 skrev Povl Ole Haarlev Olsen: On Thu, 3 Nov 2022, Flemming Bjerke wrote: Er der nogen af Jer der har nogle løsninger? Behold dit .dk domain hvor det er og nøjes med at lade hostwinds stå for rDNS for IP adressen. Nåeh ja, selvfølgelig. Tak, for hjælpen!!! No problem... Før havde jeg mine domæner hos gratisdns. Nu er de flyttet til one.com. Men one.com er lidt trættende. Man skal hele sno sig uden om forskellige tilbud, og så er deres dns lidt begrænset. Sådan var det også for mig. Jeg løste problemet ved at få mine egne maskine godkendt hos DK Hostmaster og derefter flytte DNS for mine domains til min egne DNS servere. Måske ikke en løsning, der er god for alle, men den virker fint for mig. -- Povl Ole
Re: Fanget i DNS
On Thu, 3 Nov 2022, Flemming Bjerke wrote: Hvordan løser I problemer med reverse DNS? Jeg ved, at DanskNet, Telenor og YouSee alle tre understøtter rDNS. Og med et tryk på maven og en henvisning til RFC2317/BCP20 kan man endda få dem til at redelegere rDNS for en enkelt IP-adresse til nogle andre DNS servere end deres egne. Navneserveren er ikke registreret hos DK Hostmaster Du behøver ikke bruge samme DNS servere for forward og reverse DNS. Dit .dk domain skal ganske rigtigt være på nogle servere DK Hostmaster kender, men rDNS (dvs. PTR-recorden for .in-addr.arpa) bør være på mdns3.hostwindsdns.com, hvis det er den, der er auth DNS for rDNS domænet (mailserverens IP adresse skrevet baglæns og med ".in-addr.arpa" bagefter). Er der nogen af Jer der har nogle løsninger? Behold dit .dk domain hvor det er og nøjes med at lade hostwinds stå for rDNS for IP adressen. -- Povl Ole
Re: Trådløs Firmware mangler
On Wed, 23 Mar 2016, Normann Louis Olsen wrote: Jeg har netop installeret Debian på min HP Pavilion g series computer, og det ligner en succes, bortset fra at jeg kan se, at Trådløs firmware mangler. Da du fik at vide at firmwaren manglede, fik du så også at vide hvad filen/filerne burde hedde? Hvordan får jeg fat i den? Du kan prøve at installere "firmware-linux-nonfree". Som navnet kraftig antyder, så ligger den pakke i "non-free". Hvis det ikke hjælper, så prøv at køre "lshw -C network" som root, så vi kan se hvad det er for noget hardware, der driller. -- Povl Ole
Re: Nem-login - for de lidt paranoide
On Sat, 25 Feb 2012, bjerke wrote: Den 25-02-2012 09:47, Jacob Sparre Andersen skrev: Flemming Bjerke skrev: Interessant ... men hvorfor skal kontoen nulstilles? Kan det ikke v?re lige meget? For at sikre sig at der ikke er slaebt noget uoensket snavs (som f.eks. en key-logger) ind ved en fejl. Jeg skal lige at fatte det. En keylogger i min /home/DumID ... den kan vel kun logge hvad jeg g?r n?r jeg er brugeren DumID - og der n?glekort i tegnebogen vel trods alt en slags sikkerhed. Den kan vel ikke logge hvad bjerke g?r? En keylogger ville nok starte med at proeve at lave noget privilege escalation. Hvis det lykkes for den at blive root vha. en eller anden bug, kan den goer hvad den har lyst til. Men ok, hvis den kan blive root, saa har den nok ogsaa allerede gemt noget kode uden for $HOME og saa hjaelper det ikke ret meget at wipe det dir. -- Povl Ole "Jeg saetter min soelvpapirshat som jeg vil..." Haarlev Olsen -- To UNSUBSCRIBE, email to debian-user-danish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1202252120590.17...@noget.stderr.dk.localdomain
Re: Nem-login - for de lidt paranoide
On Fri, 24 Feb 2012, Jacob Sparre Andersen wrote: Povl Ole Haarlev Olsen skrev: Jeg synes, jeg hoerte noget om, at NemID ogsaa laeser filer udenfor ${HOME}. Har du ogsaa en god loesning paa det problem? Ved at lade nemid-brugeren v?re i gruppen "nogroup", s? begr?nser du dens adgang voldsomt. Specielt hvis du husker at rettigheder til "others" skal tages meget bogstaveligt. Det er klart. Jeg har bare ikke set ret mange eksempler, hvor folk har fjernet nogroups rettigheder til at laese f.eks. /proc/net/dev, /sys/block/sda/device/model eller /etc/passwd for bare at naevne nogle af de filer, jeg ikke er interesseret i at DanID gaar og kigger i. Paa en default opsaetning af Squeeze kan nobody, der kun er i nogroup, f.eks. faa at vide at... # su -c "id ; cat /sys/block/sda/size" nobody uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup) 976773168 ... sda er en ca. 500GB disk. Det er altsaa ikke nok bare at svinge tryllestaven og sige "nogroup" og saa ellers tro, at alt er lukket ned. Skal man virkelig ud i noget med en virtual machine eller SELinux for at slippe for den slags pjat? Det skal man nok. Det maa jeg saa kigge naermere paa, hvis jeg en dag skulle vaere saa uheldig, at jeg bliver tvunget til at faa et NemID. Det bliver nok ikke foreloebig. :-) -- Povl Ole -- To UNSUBSCRIBE, email to debian-user-danish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1202241226250.17...@noget.stderr.dk.localdomain
Re: Nem-login - for de lidt paranoide
On Fri, 24 Feb 2012, Jacob Sparre Andersen wrote: Jeg er lidt sart med lukkede programmer, der kan skrive paa min disk, saa jeg har lavet en separat konto til NemID brug, der bliver nulstillet hver gang jeg logger ud: Jeg synes, jeg hoerte noget om, at NemID ogsaa laeser filer udenfor ${HOME}. Har du ogsaa en god loesning paa det problem? Skal man virkelig ud i noget med en virtual machine eller SELinux for at slippe for den slags pjat? Det skal lige siges, at jeg ikke selv har noget NemID, saa spoergsmaalet er mere af almen interesse. -- Povl Ole -- To UNSUBSCRIBE, email to debian-user-danish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1202240801220.17...@noget.stderr.dk.localdomain
Re: iptables og kernemoduler
On Fri, 17 Aug 2007, Kai Olsen wrote: > Jeg har et problem med at sætte en firewall op. Når jeg kører > /sbin/iptables aborterer programmet med begrundelsen, at modulet > 'ip_tables' ikke findes. Det har programmet for så vidt ret i - al > netfilter kode er nemlig kompileret fast ind i min selvbyggede kerne. > Er det virkeligt nødvendigt at hente sourcen til iptables og kompilere > den bare fordi man har ændret kernens konfig? > Det modarbejder lissom ideen med kernemoduler... Du kan prøve, at checke med "strace" hvilke filer og programmer iptables prøver at åbne/starte. -- paa://vegne.af/mig.selv: on://behalf.of/myself: Povl Ole "Give Me Bandwidth Or Give Me Death" Haarlev Olsen Please read http://rfc-editor.org/rfc/rfc1855.txt before replying