"hg archive" with remote URL
Kastner Masilko, Friedrich
kastner-masilko at at.festo.com
Fri Aug 9 12:32:57 UTC 2013
> From: Mutlu Dogruel [mailto:mutludogruel at gmail.com]
>
> I think you misunderstood. I was talking about automatic deployment as
> in Opscode Chef cookbooks in which there is no manual installing as
> such. Basically, it's a script running on a remote machine that does
> all the installations, fetching code from repositories etc. It makes it
> easy to setup clusters in cloud computing platforms, for example. If
> you are using the "curl" solution, you have to pass the user name &
> password to the script somehow (one solution is the use of encrypted
> databags in Chef recipes). But ideally, key-based authentication would
> work best in such setups. Having to manage temporary user names &
> passwords on a project basis is not an elegant solution.
I don't know. IMHO it doesn't really matter if it is a user machine - where the user has to install a DVCS manually and invoke the download manually - or a remote machine, where everything is done by your script. Your initial question used git's remote-archive feature as example, so how would git have been installed on the remote machine? Do you simply assume it is? Without the DVCS on the remote machine, a script running a DVCS command can't work. This is what I meant with having wget/curl being a better option, as those tools work as HTTP(S) tools and not as DVCS, with the later not really being the feature set you need for a download operation.
Besides this, wouldn't you have to embed/transfer the relevant key part, too? Is this really that different from embedding/transferring user/password? Or do you assume that the key is installed on all remote machines already?
I'd also say that in your case it would of course make more sense to use only one temporary user for this, just as you would use only one key-pair.
Maybe I'm missing something essential here (given that I don't know Chef too well), but from the general standpoint I don't understand your statement about key-based authentication working best in this situation.
Regards,
Fritz
Development Software Systems
Festo Gesellschaft m.b.H.
Linzer Strasse 227
Austria - 1140 Wien
Firmenbuch Wien
FN 38435y
UID: ATU14650108
Tel: +43(1)91075-198
Fax: +43(1)91075-282
www.festo.at
Der Inhalt dieser E-Mail und moeglicher Anhaenge sind ausschliesslich fuer den bezeichneten Adressaten bestimmt.
Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail und
moeglicher Anhaenge durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender der E-Mail in
Verbindung zu setzen, falls Sie nicht der Adressat dieser E-Mail sind sowie das Material von Ihrem Computer zu loeschen.
This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or
dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this
e-mail, please delete it and immediately notify the sender.
More information about the Mercurial
mailing list