Input voor een commando automatiseren?

[kmf]

Is er een algemene manier om bestaande commando's onder linux die vragen om interactie van de gebruikers te automatiseren? Door middel van een configfile of zo?

BV. bij de commando "passwd " waar ik tweemaal een password moet invullen, is het mogelijk om via een pipe of zo de password in te voeren? (dit is slechts een voorbeeld, kan ook een ander commando zijn waarbij je "intikken intkken" etc moet doen. )

[Verwijderd]

Alles kan, dus ook dit

Het probleem is alleen hoe. Om daarop antwoord te kunnen geven, moet je eerst vertellen wat je nu eigenlijk ECHT wil.

Voor zover ik weet is er geen generieke, algemene methode die doet hetgeen jij omschrijft. Veel hangt er van af _hoe_ die applicatie om input vraagt.

[Gomez12]

op de cli kan je gewoon zoeken naar redirect ( progje < input hierbij wordt dus input als bestand gezien en dit wordt naar het progje gestuurd als input. Werkt alleen met progjes die std-in en output gebruiken ) en piping ( progje 1 | progje 2 . progje 1's output geldt als input voor progje 2 weer alleen met std-in en output. )

Voor GUI zou ik niks weten.

[blaataaps]

Description: A program that "talks" to other programs.
Expect is a program that "talks" to other interactive programs
according to a script. Following the script, Expect knows what
can be expected from a program and what the correct response
should be. An interpreted language provides branching and high-
level control structures to direct the dialogue. In addition,
the user can take control and interact directly when desired,
afterward returning control to the script.

Dat is expect, misschien kun je daar wat mee. Sommige programma's, waaronder passwd vaak, weigeren echter input als het niet van een terminal komt vrees ik. Bepaalde versies van passwd kun je trouwens het wachtwoord meegeven op de commandline (iig bij oudere redhats was dat zo bijvoorbeeld).

[kmf]

Verwijderd schreef op 03 mei 2004 @ 19:45:
Alles kan, dus ook dit

Het probleem is alleen hoe. Om daarop antwoord te kunnen geven, moet je eerst vertellen wat je nu eigenlijk ECHT wil.

Voor zover ik weet is er geen generieke, algemene methode die doet hetgeen jij omschrijft. Veel hangt er van af _hoe_ die applicatie om input vraagt.

Alles kan idd, daar staat linux wel bekend om. Maar hoe, dat is ook idd het probleem.

Een aantal weken geleden wou ik FTPen automatiseren met crontab. Is me na lang zoeken gelukt d.m.v. .netrc en een bashscriptje.
Later zocht ik naar een manier om automatische password in te voeren bij rsync <-nog niet gelukt.
Nu zoek ik een manier om automatisch SSL-keys te genereren<- weer interactie...

en dus... vraag ik me af of er niet gewoon een algemene methode was om die dingen in te voeren.

[bkor]

blaataaps schreef op 03 mei 2004 @ 19:47:
[...]
Dat is expect, misschien kun je daar wat mee. Sommige programma's, waaronder passwd vaak, weigeren echter input als het niet van een terminal komt vrees ik.

Niet echt duidelijk of je dit al wist, maar expect gebruikt een pty zodat programma's denken dat het van een terminal afkomt. Bij expect komt ook een voorbeeld hoe je passwd kan automatiseren:

Tcl:

set password [lindex $argv 1]
spawn passwd [lindex $argv 0]
expect "password:"
send -- "$password\r"
expect "password:"
send -- "$password\r"
expect eof

Nadeel van expect is dat (hoewel logisch) je steeds een script om een programma heen moet schrijven. Dit is soms onhandig als er wat onverwachts gebeurd waar het script geen rekening mee houdt (foutmelding ofzo).
Verder heeft expect jammer genoeg geen 'terminal emulator' (vt100/vt220) in zich om bv zoiets als mutt te automatiseren (jah niet het beste voorbeeld).

[Wilke]

athlonkmf schreef op 03 mei 2004 @ 20:36:
Een aantal weken geleden wou ik FTPen automatiseren met crontab. Is me na lang zoeken gelukt d.m.v. .netrc en een bashscriptje.

Check eens 'ncftp' en dan de bijbehorende scripts 'ncftpget/put'.

Later zocht ik naar een manier om automatische password in te voeren bij rsync <-nog niet gelukt.

Voor wie nog suggesties heeft, dit topic dus: Rsync-command in cron zonder password te geven?/

In je andere topic staat nog een suggestie die prima werkt onderaan, dus ik snap niet helemaal waarom je daar niet mee verder komt: je kunt prima een SSH key maken zonder password, cq. met password en deze laten onthouden door keychain (eenmalig intikken na reboot), en dan 'password-less' inloggen op een ander systeem (dus ook scp e.d. gebruiken). Of dat ook voor rsync-over-ssh werkt weet ik trouwens niet zeker hoor...

Nu zoek ik een manier om automatisch SSL-keys te genereren<- weer interactie...

Wat voor interactie dan? Bijna alle distributies die ik ken genereren 'by default' host-keys zonder password voor SSL-verbindingen e.d., dus het lijkt me dat dit wel degelijk kan.

Algemeen gebruikte methodes zijn dus: alles is aan te sturen via de commandline, een configfile, de standard input, of een combinatie van die drie.

Er zijn juist 'expres' wat uitzonderingen gemaakt, met name waar het het invoeren van wachtwoorden betreft, om te voorkomen dat het hele nut van die dingen door nietswetende gebruikers per ongeluk ongedaan gemaakt wordt. Bv. password op de commandline is sniffbaar voor iedereen die op dat systeem 'ps' kan draaien (in de meeste gevallen, anyway). En het idee van een password is natuurlijk niet dat je het in een scriptje gooit, dan kun je net zo goed het hele password weglaten (meestal). Daarom worden passwords die niet van een tty komen vaak niet toegelaten.

Neemt niet weg dat deze beperkingen soms vrij irri zijn idd

[kmf]

Wilke schreef op 03 mei 2004 @ 23:52:
[...]

Check eens 'ncftp' en dan de bijbehorende scripts 'ncftpget/put'.

Daar was ik ook achter gekomen

Voor wie nog suggesties heeft, dit topic dus: Rsync-command in cron zonder password te geven?/

In je andere topic staat nog een suggestie die prima werkt onderaan, dus ik snap niet helemaal waarom je daar niet mee verder komt: je kunt prima een SSH key maken zonder password, cq. met password en deze laten onthouden door keychain (eenmalig intikken na reboot), en dan 'password-less' inloggen op een ander systeem (dus ook scp e.d. gebruiken). Of dat ook voor rsync-over-ssh werkt weet ik trouwens niet zeker hoor...

Ik zeg ook niet dat ik er niet mee uit de voeten kan, maar het is wel een van de redenen om deze topic te openen.

[...]

Wat voor interactie dan? Bijna alle distributies die ik ken genereren 'by default' host-keys zonder password voor SSL-verbindingen e.d., dus het lijkt me dat dit wel degelijk kan.

Hmm.. invoeren van de land, bedrijf, contactgegevens etc. Deze lukte me niet om via -config door te geven...

Algemeen gebruikte methodes zijn dus: alles is aan te sturen via de commandline, een configfile, de standard input, of een combinatie van die drie.

Er zijn juist 'expres' wat uitzonderingen gemaakt, met name waar het het invoeren van wachtwoorden betreft, om te voorkomen dat het hele nut van die dingen door nietswetende gebruikers per ongeluk ongedaan gemaakt wordt. Bv. password op de commandline is sniffbaar voor iedereen die op dat systeem 'ps' kan draaien (in de meeste gevallen, anyway). En het idee van een password is natuurlijk niet dat je het in een scriptje gooit, dan kun je net zo goed het hele password weglaten (meestal). Daarom worden passwords die niet van een tty komen vaak niet toegelaten.

Neemt niet weg dat deze beperkingen soms vrij irri zijn idd

Als ik een bak neem waarbij ik eenmaal alles goed zet en daarna geen gebruikers in wilt hebben, behalve mijzelf, dan kunnen deze beperkingen alleen maar tegen werken dan mezelf tegen mezelf beschermen. Dan is zoiets als scrippies wel zo makkelijk. Evt. kan ik natuurlijk ook een een webinterface maken die deze scrippies schrijf en dan gelijk weer delete of zo.

En was het niet zo dat linux maar vertrouwt op het weten en kunnen van de sysadmin?

[Verwijderd]

athlonkmf schreef op 04 mei 2004 @ 00:08:
Hmm.. invoeren van de land, bedrijf, contactgegevens etc. Deze lukte me niet om via -config door te geven...

Bij het geneneren van keys kun je met de openssl commandline tool verschillende manieren gebruiken om passwords mee te geven.

Meestal via de -passin parameters. Standaard wordt het password direct uit van terminal gelezen, waardoor enige vorm van IO redirection bijna onmogelijk wordt. Andere mogelijkheden zijn:

-passin stdin leest logischerwijs van de stdin
-passin pass:p4ssw0rd leest direct van de CLI
-passin env:varname leest uit een enviroment variable

Met tools als expect of een simple cat filename | openssl .... zou het ook moeten kunnen om land, bedrijf, contactgegevens e.d. uit te lezen. Deze worden zover ik weet namelijk gewoon van de stdin gelezen.