|
| Ændre password på admin i Webmin Fra : René Frej Nielsen |
Dato : 06-04-02 17:00 |
|
Hejsa,
For det første: Jeg er en typisk newbie, som nok kommer til at plage jer
lidt for fremtiden, da jeg konstant løber ind i problemer med *nix.
Nå, mit første problem er ret dumt... Jeg har installeret FreeBSD 4.5
via ftp for godt en måned siden, hvor jeg også installerede Webmin. Det
gik sådan set fint, men jeg ikke haft tid til at kigge på det siden.
Nu ville jeg så til at rode med det (så jeg kunne komme med andre dumme
spørgsmål), men jeg kan dælme ikke huske passwordet til admin brugeren i
Webmin! Jeg har prøvet mine typiske password, men jeg må have brugt et
eller genialt under installationen; et eller andet som jeg aldrig ville
glemme... Nå, men på Webmin sitet kan jeg se, at det er ret nemt at
ændre password på admin brugen. Man skal bare eksekvere changepass.pl
med et par kommandoer.
Jeg har fundet changepass.pl, men den vil ikke eksekvere den. Jeg får
bare en:
changepass.pl: Command not found.
Hvis jeg skriver ls -F, så skriver den en * ud for changepass.pl, så den
burde da være eksekverbar, eller hvad?
Er der nogen der kan hjælpe, eller skal jeg ud i en reinstallation?
--
Mvh.
René Frej Nielsen
| |
Martin C. Petersen (06-04-2002)
| Kommentar Fra : Martin C. Petersen |
Dato : 06-04-02 18:44 |
|
René Frej Nielsen wrote:
> changepass.pl: Command not found.
../changepass.pl
måske?
mvh
Martin
| |
René Frej Nielsen (07-04-2002)
| Kommentar Fra : René Frej Nielsen |
Dato : 07-04-02 00:19 |
|
In article <3CAF33D4.1060906@fyrreklitten.dk>,
"Martin C. Petersen" <nospam@fyrreklitten.dk> wrote:
> René Frej Nielsen wrote:
> > changepass.pl: Command not found.
> ./changepass.pl
> måske?
Det var det! Hvad gør ./ egentlig?
--
Mvh.
René Frej Nielsen
| |
Bo Simonsen (07-04-2002)
| Kommentar Fra : Bo Simonsen |
Dato : 07-04-02 01:44 |
|
On Sun, 07 Apr 2002 01:18:43 +0200
René Frej Nielsen <rfn@mac.com> wrote:
> Det var det! Hvad gør ./ egentlig?
Et unix system opfatter kommandoen 'test' som en exekverbar fil der ligger i PATH envoriment variablen (test det med 'echo $PATH'). Men derimod opfatter unix systemet './test' som en exekverbar fil der ligger i bibloteket.
Undre mig over hvorfor dette ikke står i Friheden til Unix ( www.sslug.dk -> linuxbøger), da det er ret hensigtmæssigt at kunne.
--
Med venlig hilsen
Bo Simonsen
Join the GNU generation!
| |
René Frej Nielsen (07-04-2002)
| Kommentar Fra : René Frej Nielsen |
Dato : 07-04-02 02:21 |
|
In article <20020407024402.0a31582a.paltas@geekworld.dk>,
Bo Simonsen <paltas@geekworld.dk> wrote:
> On Sun, 07 Apr 2002 01:18:43 +0200
> René Frej Nielsen <rfn@mac.com> wrote:
>
> > Det var det! Hvad gør ./ egentlig?
>
> Et unix system opfatter kommandoen 'test' som en exekverbar fil der ligger i
> PATH envoriment variablen (test det med 'echo $PATH'). Men derimod opfatter
> unix systemet './test' som en exekverbar fil der ligger i bibloteket.
Altså sagt på newbie sprog:
Hvis man bare skriver en kommando, så vil Unix kigge efter den i de
stier, der er defineret i PATH og ingen andre steder. Hvis man skriver
../ foran, kan man eksekvere en kommando uanset hvor den ligger.
Er det korrekt?
> Undre mig over hvorfor dette ikke står i Friheden til Unix ( www.sslug.dk ->
> linuxbøger), da det er ret hensigtmæssigt at kunne.
Ja. Jeg har haft brug for den et par gange, men har glemt det i
mellemtiden. Tak for genopfriskelsen.
--
Mvh.
René Frej Nielsen
| |
Claus Rasmussen (07-04-2002)
| Kommentar Fra : Claus Rasmussen |
Dato : 07-04-02 02:38 |
|
René Frej Nielsen wrote:
> Altså sagt på newbie sprog:
>
> Hvis man bare skriver en kommando, så vil Unix kigge efter den i de
> stier, der er defineret i PATH og ingen andre steder. Hvis man skriver
> ./ foran, kan man eksekvere en kommando uanset hvor den ligger.
>
> Er det korrekt?
Nej ikke helt. Det er rigtigt, at et unix system vil kigge i de kataloger,
der er med i pathen, _hvis_ man ikke giver en sti til kommandoen.
Når du skriver './' før kommandoen betyder det nemlig, at du fortæller
bash (som faktisk er den ansvarlige), at det program, du vil udføre
ligger i det aktuelle katalog. Du kunne i stedet skifte til kataloget
ovenover dit program og så bruge kommandoen 'katalog/kommando' og få
nøjagtigt det samme resultat.
Der er så ydermere den specialitet, at root brugeren har en anden PATH
end almindelige dødelige brugere: Almindlige brugere har normalt ikke
/sbin og /usr/sbin med i deres PATH, men til gengæld ./ med. Dvs. at
almindelige brugere vil kunne nøjes med at skrive 'kommando' i stedet
for './kommando', hvis de står i det katalog, hvor programmet ligger.
Når root ikke har ./ med i pathen skyldes det, at man ellers ville kunne
cracke maskinen, hvis man lagde et ondt script i sit hjemmekatalog med
navnet 'ls'. Den dag root brugeren kom forbi og lige ville kigge, hvad
der lå i katalget med 'ls' komandoen, ville du med et tilstrækkeligt
ondsindet script kunne smadre maskinen.
-Claus
| |
René Frej Nielsen (07-04-2002)
| Kommentar Fra : René Frej Nielsen |
Dato : 07-04-02 10:15 |
|
In article <a8o7th$5ql$1@sunsite.dk>,
Claus Rasmussen <clr@cc-consult.dk> wrote:
> René Frej Nielsen wrote:
>
> > Altså sagt på newbie sprog:
> >
> > Hvis man bare skriver en kommando, så vil Unix kigge efter den i de
> > stier, der er defineret i PATH og ingen andre steder. Hvis man skriver
> > ./ foran, kan man eksekvere en kommando uanset hvor den ligger.
> >
> > Er det korrekt?
>
> Nej ikke helt. Det er rigtigt, at et unix system vil kigge i de kataloger,
> der er med i pathen, _hvis_ man ikke giver en sti til kommandoen.
>
> Når du skriver './' før kommandoen betyder det nemlig, at du fortæller
> bash (som faktisk er den ansvarlige), at det program, du vil udføre
> ligger i det aktuelle katalog. Du kunne i stedet skifte til kataloget
> ovenover dit program og så bruge kommandoen 'katalog/kommando' og få
> nøjagtigt det samme resultat.
OK.
> Der er så ydermere den specialitet, at root brugeren har en anden PATH
> end almindelige dødelige brugere: Almindlige brugere har normalt ikke
> /sbin og /usr/sbin med i deres PATH, men til gengæld ./ med. Dvs. at
> almindelige brugere vil kunne nøjes med at skrive 'kommando' i stedet
> for './kommando', hvis de står i det katalog, hvor programmet ligger.
>
> Når root ikke har ./ med i pathen skyldes det, at man ellers ville kunne
> cracke maskinen, hvis man lagde et ondt script i sit hjemmekatalog med
> navnet 'ls'. Den dag root brugeren kom forbi og lige ville kigge, hvad
> der lå i katalget med 'ls' komandoen, ville du med et tilstrækkeligt
> ondsindet script kunne smadre maskinen.
Ja, det kan jeg jo godt se. Det er jo lidt indviklet det her, men det
var da fedt at få det forklaret. Tak for den udførlige beskrivelse!
--
Mvh.
René Frej Nielsen
| |
DUdsen (07-04-2002)
| Kommentar Fra : DUdsen |
Dato : 07-04-02 17:15 |
|
Claus Rasmussen wrote:
> René Frej Nielsen wrote:
>
>> Altså sagt på newbie sprog:
>>
>> Hvis man bare skriver en kommando, så vil Unix kigge efter den i de
>> stier, der er defineret i PATH og ingen andre steder. Hvis man skriver
>> ./ foran, kan man eksekvere en kommando uanset hvor den ligger.
>>
>> Er det korrekt?
>
> Nej ikke helt. Det er rigtigt, at et unix system vil kigge i de kataloger,
> der er med i pathen, _hvis_ man ikke giver en sti til kommandoen.
>
> Når du skriver './' før kommandoen betyder det nemlig, at du fortæller
> bash (som faktisk er den ansvarlige), at det program, du vil udføre
> ligger i det aktuelle katalog. Du kunne i stedet skifte til kataloget
> ovenover dit program og så bruge kommandoen 'katalog/kommando' og få
> nøjagtigt det samme resultat.
..
/ betyder det aktive katalig ../ er kataloget før deraf cd .. cd .. er ofte
er alised (at man i sin .bashrc har givet en komando et ekstre navn) en
komando) til cd..
> Der er så ydermere den specialitet, at root brugeren har en anden PATH
> end almindelige dødelige brugere: Almindlige brugere har normalt ikke
> /sbin og /usr/sbin med i deres PATH, men til gengæld ./ med. Dvs. at
> almindelige brugere vil kunne nøjes med at skrive 'kommando' i stedet
> for './kommando', hvis de står i det katalog, hvor programmet ligger.
den precise udfomning af path er absplut ikke særligt standardiceret. og
variere ra distribution til distribution og som alt andet i linux kan både
bruger og systemadministrator ændre på den.
| |
|
|