---

Hej Gruppe!
Jeg har en server stående, som der er blokeret root adgang via SSH.
Er det på nogen måde muligt at give en enkelt maskine lov til at logge
ind som root.
PermitRootLogin no

Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!

--
----------------------
Med Venlig Hilsen
Per Jørgensen
Stud. Datamatiker
Archlinux 0.7.2
Ubuntu 6.06LTS
Debian Sarge

---

Per Jørgensen wrote:
> Jeg har en server stående, som der er blokeret root adgang via SSH.
> Er det på nogen måde muligt at give en enkelt maskine lov til at logge
> ind som root.
> PermitRootLogin no
>
> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
> at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!

Hvorfor er det at du har brug for root-login via ssh?

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler skrev:
> Per Jørgensen wrote:
>> Jeg har en server stående, som der er blokeret root adgang via SSH.
>> Er det på nogen måde muligt at give en enkelt maskine lov til at logge
>> ind som root.
>> PermitRootLogin no
>>
>> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
>> at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>
> Hvorfor er det at du har brug for root-login via ssh?
>
> Mvh. Michael.
Da jeg gerne vil kunne tage backup af nogle bestemte filer via rsync !
Istedet for at skulle ændre rettigheder på de filer som jeg gerne vil
tage backup af - så var dette nemmere at give 1 maskine lov til at logge
ind som root.


--
----------------------
Med Venlig Hilsen
Per Jørgensen
Stud. Datamatiker
Archlinux 0.7.2
Ubuntu 6.06LTS
Debian Dapper
Gentoo2006

---

Per Jørgensen wrote:
> Michael Zedeler skrev:
>> Per Jørgensen wrote:
>>> Jeg har en server stående, som der er blokeret root adgang via SSH.
>>> Er det på nogen måde muligt at give en enkelt maskine lov til at
>>> logge ind som root.
>>> PermitRootLogin no
>>>
>>> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse
>>> til at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>>
>> Hvorfor er det at du har brug for root-login via ssh?
>>
>> Mvh. Michael.
> Da jeg gerne vil kunne tage backup af nogle bestemte filer via rsync !
> Istedet for at skulle ændre rettigheder på de filer som jeg gerne vil
> tage backup af - så var dette nemmere at give 1 maskine lov til at logge
> ind som root.
>
>
Hvorfor ikke bare lokke ind som almindelig bruger, og derefter skifte
til root med kommandoen `su -`.

---

Den Sat, 26 Aug 2006 11:14:15 +0200 skrev Per Kofod:
> Per Jørgensen wrote:
>> Michael Zedeler skrev:
>>> Per Jørgensen wrote:
>>>> Jeg har en server stående, som der er blokeret root adgang via SSH.
>>>> Er det på nogen måde muligt at give en enkelt maskine lov til at
>>>> logge ind som root.
>>>> PermitRootLogin no
>>>>
>>>> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse
>>>> til at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>>>
>>> Hvorfor er det at du har brug for root-login via ssh?
>>>
>>> Mvh. Michael.
>> Da jeg gerne vil kunne tage backup af nogle bestemte filer via rsync !
>> Istedet for at skulle ændre rettigheder på de filer som jeg gerne vil
>> tage backup af - så var dette nemmere at give 1 maskine lov til at logge
>> ind som root.
>>
>>
> Hvorfor ikke bare lokke ind som almindelig bruger, og derefter skifte
> til root med kommandoen `su -`.

Hvordan får du rsync til at bruge su?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sat, 26 Aug 2006 11:00:10 +0200, Per Jørgensen wrote:

> Da jeg gerne vil kunne tage backup af nogle bestemte filer via rsync !
> Istedet for at skulle ændre rettigheder på de filer som jeg gerne vil
> tage backup af - så var dette nemmere at give 1 maskine lov til at logge
> ind som root.
Ville det ikke være smartere at installere den pågældende maskines
offentlige nøgle på serveren, så er du helt ude over login.

Det du formentlig søger er forced-commands-only:
PermitRootLogin
If this option is set to ``forced-commands-only'' root login with
public key authentication will be allowed, but only if the
command option has been specified (which may be useful for taking
remote backups even if root login is normally not allowed). All
other authentication methods are disabled for root.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen skrev:
> On Sat, 26 Aug 2006 11:00:10 +0200, Per Jørgensen wrote:
>
>> Da jeg gerne vil kunne tage backup af nogle bestemte filer via rsync !
>> Istedet for at skulle ændre rettigheder på de filer som jeg gerne vil
>> tage backup af - så var dette nemmere at give 1 maskine lov til at logge
>> ind som root.
> Ville det ikke være smartere at installere den pågældende maskines
> offentlige nøgle på serveren, så er du helt ude over login.
>
> Det du formentlig søger er forced-commands-only:
> PermitRootLogin
> If this option is set to ``forced-commands-only'' root login with
> public key authentication will be allowed, but only if the
> command option has been specified (which may be useful for taking
> remote backups even if root login is normally not allowed). All
> other authentication methods are disabled for root.
>
Hmmm... Nu har jeg laget lidt med det og kigget lidt i man pages.
Til at starte med:
Jeg har kopieret maskinens nøgle over på serveren og det virker - så længe
PermitRootLogin yes
er sat!

Hvis jeg sætter
PermitRootLogin forced-commands-only
Virker dette lille trick ikke mere. Jeg har lige smidt en del af min
conf fil med på /etc/ssh/sshd_config
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication yes
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

Jeg har også leget lidt med de nederste eftersom Det også gerne skulle
virke. MEN spørgsmålet er - skal BACKUP maskinen også stå i serverens
known_host eller er der et eller andet der mangler?



--
----------------------
Med Venlig Hilsen
Per Jørgensen
Stud. Datamatiker
Archlinux 0.7.2
Ubuntu 6.06LTS
Debian Dapper
Gentoo2006

---

Per Jørgensen wrote:
> Michael Zedeler skrev:
>
>> Per Jørgensen wrote:
>>
>>> Jeg har en server stående, som der er blokeret root adgang via SSH.
>>> Er det på nogen måde muligt at give en enkelt maskine lov til at
>>> logge ind som root.
>>> PermitRootLogin no
>>>
>>> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse
>>> til at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>>
>> Hvorfor er det at du har brug for root-login via ssh?
>
> Da jeg gerne vil kunne tage backup af nogle bestemte filer via rsync !
> Istedet for at skulle ændre rettigheder på de filer som jeg gerne vil
> tage backup af - så var dette nemmere at give 1 maskine lov til at logge
> ind som root.

Jeg har et backup-system som virker den anden vej. Når en maskine skal
have taget backup, starter der et lokalt job på den, som streamer
backup-filen til backup-serveren. Dermed behøver ingen af maskinerne at
have root-adgang på den anden maskine (men cron-jobbet som udfører
backup, skal selvfølgelig køre som root). Jeg ved ikke hvordan det ville
spille med rsync - jeg bruger tar.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler <michael@zedeler.dk> writes:

>Jeg har et backup-system som virker den anden vej. Når en maskine skal
>have taget backup, starter der et lokalt job på den, som streamer
>backup-filen til backup-serveren.

Det er en glimrende ide til små installationer. Men på større er
det lidt svært at have med at gøre: man er kan ikke rigtig få at
vide, om alle backups er kørt, og om de allesammen gik godt.

Hvis en maskine f.eks. crasher 95% af vejen gennem backuppen, så
er der jo kommet noget til serveren. Det er bare svært at lave et
script, der på serveren tjekker, om alt er færdigt og komplet.

En anden fejlkilde kunne være, at tar piber over et eller andet -
måske noget NFS med soft failure. tar-filen på backupserveren er
komplet, men den mangler måske de mest kritiske filer.

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> writes:

> Hvis en maskine f.eks. crasher 95% af vejen gennem backuppen, så
> er der jo kommet noget til serveren. Det er bare svært at lave et
> script, der på serveren tjekker, om alt er færdigt og komplet.

tar-filer har da et veldefineret slutmærke.

--
Thorbjørn Ravn Andersen

---

nospam0000@gmail.com (=?iso-8859-1?q?Thorbjørn_Ravn_Andersen?=) writes:

>tar-filer har da et veldefineret slutmærke.

Men ikke ét der definerer, om der mangler filer i arkivet, fordi
de bemeldte filer slet ikke fandtes på serveren.

Og så skalerer det stadig ikke rigtig...

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> writes:

> >tar-filer har da et veldefineret slutmærke.
>
> Men ikke ét der definerer, om der mangler filer i arkivet, fordi
> de bemeldte filer slet ikke fandtes på serveren.

Nix. Det er jo ikke superavanceret. Spørgsmålet er jo hvad man har
brug for.

> Og så skalerer det stadig ikke rigtig...

Næ, men du plejer da at få at vide om processen i den andenn ende døde
brat eller lukkede pænt ned.

Hvis skaleringen er et problem, er det måske tiden at overveje noget
lidt mere avanceret.

--
Thorbjørn Ravn Andersen

---

Klaus Ellegaard wrote:

> Michael Zedeler <michael@zedeler.dk> writes:
>
>>Jeg har et backup-system som virker den anden vej. Når en maskine skal
>>have taget backup, starter der et lokalt job på den, som streamer
>>backup-filen til backup-serveren.
>
> Det er en glimrende ide til små installationer. Men på større er
> det lidt svært at have med at gøre: man er kan ikke rigtig få at
> vide, om alle backups er kørt, og om de allesammen gik godt.
>
> Hvis en maskine f.eks. crasher 95% af vejen gennem backuppen, så
> er der jo kommet noget til serveren. Det er bare svært at lave et
> script, der på serveren tjekker, om alt er færdigt og komplet.

Well, du kunne jo få klienten til at uploade en logfil som det sidste den
gør. Hvis der ikke er nogen logfil, blev backupen ikke udført. Hvis der
opstod fejl, fremgår det af loggen.

--
| Christian Iversen | Food now? With marrow, the yummy bit of |
| chrivers@iversen-net.dk | humans? |

---

Christian Iversen <chrivers@iversen-net.dk> writes:

>Well, du kunne jo få klienten til at uploade en logfil som det sidste den
>gør. Hvis der ikke er nogen logfil, blev backupen ikke udført. Hvis der
>opstod fejl, fremgår det af loggen.

Det er en mulig løsning, men den er ret tung. Når man rammer de
måske 500 logfiler om dagen, som også skal parses for fejl, vil
sikkerheden for, at alle backups faktisk er ok, falde drastisk.

Basalt set handler det om at få initieret og afsluttet backups
centralt. Så er der kun et par servere, der har hovedpinen med
at kontrollere og rapportere.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:

> Christian Iversen <chrivers@iversen-net.dk> writes:
>
>>Well, du kunne jo få klienten til at uploade en logfil som det sidste den
>>gør. Hvis der ikke er nogen logfil, blev backupen ikke udført. Hvis der
>>opstod fejl, fremgår det af loggen.
>
> Det er en mulig løsning, men den er ret tung. Når man rammer de
> måske 500 logfiler om dagen, som også skal parses for fejl, vil
> sikkerheden for, at alle backups faktisk er ok, falde drastisk.
>
> Basalt set handler det om at få initieret og afsluttet backups
> centralt. Så er der kun et par servere, der har hovedpinen med
> at kontrollere og rapportere.

Logfilerne ligger jo lokalt. Hvordan er det nemmere at gennemgå outputtet
fra 500 processor, set over 500 pipes, i forhold til outputtet fra 500
processsor i 500 filer? Misforstår jeg?

--
| Christian Iversen | This is just hurty creme - it just hurts! |
| chrivers@iversen-net.dk | |

---

Christian Iversen <chrivers@iversen-net.dk> writes:

>Logfilerne ligger jo lokalt. Hvordan er det nemmere at gennemgå outputtet
>fra 500 processor, set over 500 pipes, i forhold til outputtet fra 500
>processsor i 500 filer? Misforstår jeg?

foreach $klient .......
do
   ssh $klient tar $whatever
   if [ $? -ne 0 ]
   then   
      echo "Noget gik i stykker på $klient" >>samlet-logfil
   else
      echo "Woohooooo! Fest på $klient" >>samlet-logfil
   fi
done

Udvid på passende vis

Uanset hvad ender man her med én samlet logfil, som serveren kan
præsentere som det samlede overblik. Return-codes er noget mere
behagelige at basere sin fejlregistrering på end tekst i logfiler.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:

> Christian Iversen <chrivers@iversen-net.dk> writes:
>
>>Logfilerne ligger jo lokalt. Hvordan er det nemmere at gennemgå outputtet
>>fra 500 processor, set over 500 pipes, i forhold til outputtet fra 500
>>processsor i 500 filer? Misforstår jeg?
>
> foreach $klient .......
> do
> ssh $klient tar $whatever
> if [ $? -ne 0 ]
> then
> echo "Noget gik i stykker på $klient" >>samlet-logfil
> else
> echo "Woohooooo! Fest på $klient" >>samlet-logfil
> fi
> done
>
> Udvid på passende vis

Det prøver jeg så :)

på klienten:

#!/bin/sh
(tar ... /backupdata | ssh backupuser@server) 2> backup.log
echo $$ > backup.result
scp backup.result backup.log backupuser@server:


(køres kl "efter backupen er kørt")
#!/usr/bin/pseudocode
foreach $client do
if exists($client/backup.result) &&
contents($client/backup.result) == 0 then
echo "klienten $client OK" > samlet.log
else
echo "klienten $client NOT OK" > samlet.log
fi
....

Kan da godt være det er en anelse mere kompliceret, men ikke meget.

> Uanset hvad ender man her med én samlet logfil, som serveren kan
> præsentere som det samlede overblik. Return-codes er noget mere
> behagelige at basere sin fejlregistrering på end tekst i logfiler.

Jeg er da sådan set enig :)

--
| Christian Iversen | Mussolini said "We're all Fascists", but |
| chrivers@iversen-net.dk | most Italian people are always on scooters |
| | going, "Ciao!" |

---

Christian Iversen <chrivers@iversen-net.dk> writes:

>Kan da godt være det er en anelse mere kompliceret, men ikke meget.

Det er også en udmærket løsning. Men du er nu afhængig af 500
cron-daemoner, og det er en del mere besværligt at debugge,
hvorfor et givent backup-job ikke startede kl. 03 - eller
hvorfor det endnu ikke er færdigt kl. 08.

Den centrale løsning har den fordel, at al progress og alle
processer kan monitoreres centralt - foruden at backuppen og
den dens data også er backup-serverens eget ansvar.

YMMV

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:

> Christian Iversen <chrivers@iversen-net.dk> writes:
>
>>Kan da godt være det er en anelse mere kompliceret, men ikke meget.
>
> Det er også en udmærket løsning. Men du er nu afhængig af 500
> cron-daemoner, og det er en del mere besværligt at debugge,
> hvorfor et givent backup-job ikke startede kl. 03 - eller
> hvorfor det endnu ikke er færdigt kl. 08.

Det kommer selvfølgelig an på installationen, ja. Alternativt kunne man
sige, hvis det var 500 brugere der var tale om, at det var deres eget
problem. Så kunne overvågningssystemet sende dem en email hvis de glemte at
sende backupen til serveren.

> Den centrale løsning har den fordel, at al progress og alle
> processer kan monitoreres centralt - foruden at backuppen og
> den dens data også er backup-serverens eget ansvar.
>
> YMMV

Indeed :)

--
| Christian Iversen | And then he went to China and bought a |
| chrivers@iversen-net.dk | packed lunch |

---

Christian Iversen <chrivers@iversen-net.dk> wrote:

> scp backup.result backup.log backupuser@server:

Dybest set kan denne operation godt fejle selvom backuppen har været i
orden.

--
Allan Willems Joergensen

"Oops! I lost a button hole"

---

Allan Willems Joergensen wrote:

> Christian Iversen <chrivers@iversen-net.dk> wrote:
>
>> scp backup.result backup.log backupuser@server:
>
> Dybest set kan denne operation godt fejle selvom backuppen har været i
> orden.

Og hvis den gør det, så vil programmet på serveren jo kunne se det.

Det er fint nok - det ville være langt værre at tro at backupen havde kørt,
når den ikke havde det.

--
| Christian Iversen | I take that as a huge silent yes! |
| chrivers@iversen-net.dk | |

---

Den Sat, 26 Aug 2006 19:28:38 +0000 (UTC) skrev Klaus Ellegaard:
> Christian Iversen <chrivers@iversen-net.dk> writes:
>
>>Logfilerne ligger jo lokalt. Hvordan er det nemmere at gennemgå outputtet
>>fra 500 processor, set over 500 pipes, i forhold til outputtet fra 500
>>processsor i 500 filer? Misforstår jeg?
>
> foreach $klient .......
> do
>    ssh $klient tar $whatever
>    if [ $? -ne 0 ]
>    then   
>       echo "Noget gik i stykker på $klient" >>samlet-logfil
>    else
>       echo "Woohooooo! Fest på $klient" >>samlet-logfil
>    fi
> done

Backup af en maskine af gangen - man må håbe der er tale om få
små maskiner, for hvis det er 10 maskiner der hver tager 4 timer
at tage backup af bliver du ikke færdig idag.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>> done

>Backup af en maskine af gangen

Nejda - det er bare dig, der er en citatfusker. Du glemte:

>> Udvid på passende vis

Mvh.
   Klaus.

---

Den Sat, 26 Aug 2006 19:54:43 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> done
>
>>Backup af en maskine af gangen
>
> Nejda - det er bare dig, der er en citatfusker. Du glemte:
>
>>> Udvid på passende vis

Hvordan har du tænkt dig at udvide dem til at køre parralelt,
uden at gøre det mere kompliceret end log-filer?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>>>> Udvid på passende vis

>Hvordan har du tænkt dig at udvide dem til at køre parralelt,
>uden at gøre det mere kompliceret end log-filer?

Spredt over en række selvstændige jobs, der igen er spredt over
hele døgnet. Det kræver kun ~100 linjer plus noget overvågning.

Men jeg kan desværre ikke levere koden her, og jeg gider ikke
opfinde den igen.

Mvh.
   Klaus.

---

Den Sat, 26 Aug 2006 20:01:27 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>>>> Udvid på passende vis
>
>>Hvordan har du tænkt dig at udvide dem til at køre parralelt,
>>uden at gøre det mere kompliceret end log-filer?
>
> Spredt over en række selvstændige jobs, der igen er spredt over
> hele døgnet. Det kræver kun ~100 linjer plus noget overvågning.

"uden at gøre det mere kompliceret..."

Den komplicerede løsning med log-filerne kom op på omkring 10 linjer.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>Den komplicerede løsning med log-filerne kom op på omkring 10 linjer.

Har du praktisk erfaring med den?

Mvh.
   Klaus, der ikke synes, den var så praktisk i praksis.

---

Den Sat, 26 Aug 2006 20:08:19 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Den komplicerede løsning med log-filerne kom op på omkring 10 linjer.
>
> Har du praktisk erfaring med den?

Det er ti minutter siden den blev postet, hvad tror du selv?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>> Har du praktisk erfaring med den?

>Det er ti minutter siden den blev postet, hvad tror du selv?

Med princippet så?

Det var jo hele ideen med mit første indlæg i denne tråd: jeg gjorde
opmærksom på, at den distribuerede løsning ikke skalerer. Den virker
fint i "det små", og Christians koncept er ganske glimrende.

Men når det skal skalere, så bliver det tungt. Og fejlhåndteringen
og ikke mindst logging/dokumentation er efter min erfaring nemmere,
når den foregår centralt (både i det små og det store). Hvilket igen
var en støtte til Pers første koncept med at lade backupserveren
snakke med klienten og ikke omvendt.

Det er altid nemt at lave et backup-script. Men er det så solidt,
at outputtet kan bruges til at lave en restore i morgen? Om tre
måneder? Om fem år? Når du mindst venter det?

Mvh.
   Klaus.

---

Den Sat, 26 Aug 2006 20:19:28 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> Har du praktisk erfaring med den?
>
>>Det er ti minutter siden den blev postet, hvad tror du selv?
>
> Med princippet så?

"Vi" har mig bekendt aldrig brugt andet.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 2006-08-26, Kent Friis <nospam@nospam.invalid> wrote:
>>
>>>Backup af en maskine af gangen
>>
>> Nejda - det er bare dig, der er en citatfusker. Du glemte:
>>
>>>> Udvid på passende vis
>
> Hvordan har du tænkt dig at udvide dem til at køre parralelt,
> uden at gøre det mere kompliceret end log-filer?

Ved at fork()e passende steder?

--
Andreas

---

Klaus Ellegaard wrote:
> Michael Zedeler <michael@zedeler.dk> writes:
>
>
>>Jeg har et backup-system som virker den anden vej. Når en maskine skal
>>have taget backup, starter der et lokalt job på den, som streamer
>>backup-filen til backup-serveren.
>
> Det er en glimrende ide til små installationer. Men på større er
> det lidt svært at have med at gøre: man er kan ikke rigtig få at
> vide, om alle backups er kørt, og om de allesammen gik godt.

Enig. På en større installation, ville jeg også bruge et backupsystem,
som ikke bare er et par utilities bundet sammen med noget script-kode og
en rulle gaffatape, som jeg beskrev det. Der findes jo masser af
systemer, som håndterer den slags pænt.

> Hvis en maskine f.eks. crasher 95% af vejen gennem backuppen, så
> er der jo kommet noget til serveren. Det er bare svært at lave et
> script, der på serveren tjekker, om alt er færdigt og komplet.

Det problem løser man ikke ved at vende kalderetningen. Om det er en
server med fuld ssh-adgang eller om det er klienten selv (delvist i
samarbejde med serveren), gør ikke den store forskel. Når endelig man er
ude i at skrue sine egne løsninger sammen, mener jeg at man er nødt til
at være ekstra varsom med sikkerhedsmæssige problemer. Hellere en
håndfuld maskiner som tager backup af sig selv (efter bedste evne) og
sender filerne (via en protokol med begrænset adgang) til en central
server, frem for en central server med fuld ssh-adgang til de andre.

> En anden fejlkilde kunne være, at tar piber over et eller andet -
> måske noget NFS med soft failure. tar-filen på backupserveren er
> komplet, men den mangler måske de mest kritiske filer.

Hvis man endegyldigt vil løse den slags, må man få fat i noget software
skrevet til formålet.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler <michael@zedeler.dk> writes:

>Enig. På en større installation, ville jeg også bruge et backupsystem,
>som ikke bare er et par utilities bundet sammen med noget script-kode og
>en rulle gaffatape, som jeg beskrev det. Der findes jo masser af
>systemer, som håndterer den slags pænt.

Det ved jeg ikke rigtig... jeg har 12 års erfaring med alt fra
Legato til TSM. Uanset hvordan man vender og drejer det, er det
umuligt ikke at komme ud i kreative løsninger, fordi ingen af
standardløsningerne er gode nok.

I mange tilfælde siger erfaringen, at den bedste løsning faktisk
er hjemmestrik, der ender med at levere til TSM. Men stadig er
det vigtigt, at det er serveren, der starter jobbet. Ellers
ryger overblikket.

>> Hvis en maskine f.eks. crasher 95% af vejen gennem backuppen, så
>> er der jo kommet noget til serveren. Det er bare svært at lave et
>> script, der på serveren tjekker, om alt er færdigt og komplet.

>Det problem løser man ikke ved at vende kalderetningen.

Jo, så længe du har en return-code, der direkte ryger tilbage til
serveren, og som intet kan "pille ved" undervejs, er man meget
langt.

>> En anden fejlkilde kunne være, at tar piber over et eller andet -
>> måske noget NFS med soft failure. tar-filen på backupserveren er
>> komplet, men den mangler måske de mest kritiske filer.

>Hvis man endegyldigt vil løse den slags, må man få fat i noget software
>skrevet til formålet.

Der findes ikke software til "alting". Hvor finder man f.eks. en
supported hyldevare til backup af en 10 år gammel SAP-version, som
af mange forskellige årsager ikke kan opgraderes? Og kan der gives
en garanti for, at denne løsning også er supported om 5 år?

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Michael Zedeler <michael@zedeler.dk> writes:
>
>>Enig. På en større installation, ville jeg også bruge et backupsystem,
>>som ikke bare er et par utilities bundet sammen med noget script-kode og
>>en rulle gaffatape, som jeg beskrev det. Der findes jo masser af
>>systemer, som håndterer den slags pænt.
>
> Det ved jeg ikke rigtig... jeg har 12 års erfaring med alt fra
> Legato til TSM. Uanset hvordan man vender og drejer det, er det
> umuligt ikke at komme ud i kreative løsninger, fordi ingen af
> standardløsningerne er gode nok.
>
> I mange tilfælde siger erfaringen, at den bedste løsning faktisk
> er hjemmestrik, der ender med at levere til TSM. Men stadig er
> det vigtigt, at det er serveren, der starter jobbet. Ellers
> ryger overblikket.

Så er det fordi du trods alt arbejder i miljøer, der er blandede nok,
til at have den slags problemer. Der findes også et mellemsegment af
virksomhedr, som godt kan klare sig med hyldevarer. Jeg er helt enig i
at man i endnu større miljøer hurtigt kan få problemer med at få de
større backup-systemer til at virke.

>>>Hvis en maskine f.eks. crasher 95% af vejen gennem backuppen, så
>>>er der jo kommet noget til serveren. Det er bare svært at lave et
>>>script, der på serveren tjekker, om alt er færdigt og komplet.
>
>>Det problem løser man ikke ved at vende kalderetningen.
>
> Jo, så længe du har en return-code, der direkte ryger tilbage til
> serveren, og som intet kan "pille ved" undervejs, er man meget
> langt.

Klart. Jeg kom vist til at kommentere noget andet, end det jeg
oprindeligt ville.

>>>En anden fejlkilde kunne være, at tar piber over et eller andet -
>>>måske noget NFS med soft failure. tar-filen på backupserveren er
>>>komplet, men den mangler måske de mest kritiske filer.
>
>>Hvis man endegyldigt vil løse den slags, må man få fat i noget software
>>skrevet til formålet.
>
> Der findes ikke software til "alting". Hvor finder man f.eks. en
> supported hyldevare til backup af en 10 år gammel SAP-version, som
> af mange forskellige årsager ikke kan opgraderes? Og kan der gives
> en garanti for, at denne løsning også er supported om 5 år?

Jeg tror blot vi tænker på forskellige problemer. Jeg forestiller mig en
stor, homogen gruppe at Linux-baserede systemer (da det er hvad
diskussionen tog udgangspunkt i), hvor man blot ønsker at centralisere
backupfunktionen. Hvis du begynder at tilføje en masse esoteriske
legacy-systemer, er det straks meget værre.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler <michael@zedeler.dk> writes:

>Jeg tror blot vi tænker på forskellige problemer. Jeg forestiller mig en
>stor, homogen gruppe at Linux-baserede systemer (da det er hvad
>diskussionen tog udgangspunkt i), hvor man blot ønsker at centralisere
>backupfunktionen. Hvis du begynder at tilføje en masse esoteriske
>legacy-systemer, er det straks meget værre.

Der er jeg helt enig med dig.

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> wrote in news:ed13ja$pdr$1
@news.klen.dk:

> Michael Zedeler <michael@zedeler.dk> writes:
>
>>Jeg tror blot vi tænker på forskellige problemer. Jeg forestiller mig en
>>stor, homogen gruppe at Linux-baserede systemer (da det er hvad
>>diskussionen tog udgangspunkt i), hvor man blot ønsker at centralisere
>>backupfunktionen. Hvis du begynder at tilføje en masse esoteriske
>>legacy-systemer, er det straks meget værre.
>
> Der er jeg helt enig med dig.

Nu da der er gået backup-snak i tråden:

Er der nogen af jer, der har erfaring med:

http://backuppc.sourceforge.net/

Jeg bruger for tiden det go'e gamle mirror script:

http://mirror.actusa.net/pub/sample-files/mirror.dist

Mvh. NKJensen

--
DYT ikke ved E-mail

---

Niels Kristian Jensen <midlertidigDYT2005@interDYTnetgruppen.dk> writes:

>
> Nu da der er gået backup-snak i tråden:
>
> Er der nogen af jer, der har erfaring med:
>
> http://backuppc.sourceforge.net/
>
> Jeg bruger for tiden det go'e gamle mirror script:
>
> http://mirror.actusa.net/pub/sample-files/mirror.dist
>

Hej NKJ

Worksforme! Har et par gange brugt den til at undo'e en cvs update der
gav et inkonsitent kit.

Jeg blev dog aldrig færdig med at sætte den op til backup af
Windows-maskinen. Vist noget med, at jeg har sat sikkerheden relativt
højt på NT, så Linux-æsken skal præstere et password for at
connecte via samba. Og det fik jeg ikke anbragt rigtigt hos backuppc.

Long time no see!

--
Mogens Dybæk Christensen
e-mail mdc at mail dot tele dot dk

---

Per Jørgensen <pj4a@dmusyd.edu> writes:

> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
> at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!

Jeg går ud fra at sudo er prøvet og ikke interessant?

Skift til public key i stedet og hold nøglen på den enlige
supermaskine.

--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen skrev:
> Per Jørgensen <pj4a@dmusyd.edu> writes:
>
>> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
>> at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>
> Jeg går ud fra at sudo er prøvet og ikke interessant?
>
> Skift til public key i stedet og hold nøglen på den enlige
> supermaskine.
>
Jeg skal bare være sikker - for jeg troede at selvom jeg lavede
SSH-nøgler til backup maskinen - så ville det blive blokeret inden
nøglen blev "godkendt" altså at uanset hvad - så hvis brugernavnet var
root - så vbar der bare lukket.
Men eftrersom jeg kan forstå på jeres snak - så tricket med SSH-nøgler
gør at man kan logge ind som root - Så ja det var min løsning.
Var bare at opfattelsen at man blev blokeret inden man kom så langt ind!

Takker mange gange!


--
----------------------
Med Venlig Hilsen
Per Jørgensen
Stud. Datamatiker
Archlinux 0.7.2
Ubuntu 6.06LTS
Debian Dapper
Gentoo2006

---

On 2006-08-26, Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
>
> Skift til public key i stedet og hold nøglen på den enlige
> supermaskine.

Og sæt authorized_keys op så den key ikke kan andet end at tage backup.

--
Andreas

---

Per Jørgensen skrev:
> Hej Gruppe!
> Jeg har en server stående, som der er blokeret root adgang via SSH.
> Er det på nogen måde muligt at give en enkelt maskine lov til at logge
> ind som root.
> PermitRootLogin no
>
> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
> at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>
Jamen tak allesammen for hurtigt svar!


--
----------------------
Med Venlig Hilsen
Per Jørgensen
Stud. Datamatiker
Archlinux 0.7.2
Ubuntu 6.06LTS
Debian Dapper
Gentoo2006

---

Per Jørgensen skrev:
> Hej Gruppe!
> Jeg har en server stående, som der er blokeret root adgang via SSH.
> Er det på nogen måde muligt at give en enkelt maskine lov til at logge
> ind som root.
> PermitRootLogin no
>
> Alstå nu er der totalt blokeret for alle - kan jeg give tilladelse til
> at maskinen på f.eks 172.16.0.5 må logge ind via SSH som root!
>
Jeg vil nok sige som Michael rasmussen var inde på er løsningen følgende:
http://www.jdmz.net/ssh/

--
----------------------
Med Venlig Hilsen
Per Jørgensen
Stud. Datamatiker
Archlinux 0.7.2
Ubuntu 6.06LTS
Debian Dapper
Gentoo2006