On Sun, Jun 14, 2009 at 10:39 PM, Jeff Forcier<[email protected]> wrote: > It now only adds the host > suffix if it would operate on >1 host
This is potentially troublesome. Consider that you are writing a script that needs to operate on an arbitrary number of hosts, perhaps decided at run time through some means. Then this is the sort of thing that could make a script blow up, if the host list contains just a single host one day, for whatever reason. Or the other way around: I'm writing my fabfile and testing it against a test server, but the first time I try it on staging or production it blows up because now there's suddenly more than one host. I think that while behavior *may* be configurable, it *should* be consistent. Or in other words: the world is simpler when rules don't have exceptions. Just my 2c. :) > , does both local and remote > tilde expansion, and will also do the right thing instead of > complaining (which was the Paramiko default) when given a local > directory name. > > Best, > Jeff > > On Fri, Jun 12, 2009 at 4:22 PM, Jeff Forcier<[email protected]> wrote: >> On Fri, Jun 12, 2009 at 3:56 PM, Timothee Besset<[email protected]> wrote: >> >>> Yep, I understand that, the problem is the lack of control, e.g. I am >>> not able to change the scheme for where the files go locally and under >>> what name. >> >> Well, as mentioned all get() currently does is append a suffix, but >> otherwise you should have full control over the local path and name. >> If it's not working as expected (e.g. passing a full relative or >> absolute path as ``local_path`` is not working) I'd be interested in >> the circumstances :) All we do is use paramiko's sftp.get() method, >> which I imagine is pretty flexible in this regard. >> >>> Another unrelated question while I'm there, one of the main problems I >>> had when I initially tried fabric, was the ability to run jobs on >>> multiple systems that use different sets of credentials. >> >> You can pass in the username in host strings, e.g. us...@host1, >> us...@host2, etc. This will work anywhere host strings are accepted: >> the global -H command line parameter, or per-command options (fab >> foo:hosts=us...@host1) or in-fabfile setting of env.hosts, and so on >> and so forth. >> >> Passwords, you should always be prompted every time a different remote >> system asks for a password, and while you *can* press Enter to use the >> last password entered, you may always re-enter a different password. >> >> So if you're looking at 3 distinct hosts with 3 distinct usernames and >> password combinations, you should be able to do: >> >> $ fab -H us...@host1,us...@host2,us...@host3 do_my_stuff >> ... >> Password for us...@host1: <enter user1 password here> >> ... >> Password for us...@host2 [Enter for previous]: <enter user2 password here> >> ... >> Password for us...@host3 [Enter for previous]: <user3 password> >> >> If there's an angle I'm missing here, let me know :) Note that there >> are plans to have per-host settings be much more robust than this, >> including the ability to specify individual per-host passwords before >> the fact and thus not have to get prompted for them at all. >> >> I'm guessing this will be in for 1.0 (0.9 final should be out >> relatively soon and no big new features are going to appear for it.) >> >> -Jeff >> > > > _______________________________________________ > Fab-user mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/fab-user > -- Venlig hilsen / Kind regards, Christian Vest Hansen. _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
