Hi, I was discussing with Daniel about the best way to pass the ssh password when using such kind of uri: 'xen+libssh2:// root(a)192.168.0.10?sshauth=password' As it seems passing the password in the uri is not a good option, maybe we can grab it from auth conf ? it seems it's not the case as now (tell me if i am wrong). So enclosed a patch to add this feature. As you can see in virnetclient.c there is no virAuthGetPassword call, so the authfile is never used. The patch enclosed is modifying the function prototype to add virConnectPtr parameter (so remote_driver.c virNetClientNewLibSSH2 call has to be updated too and the corresponding .h too). Once we have access to virConnectPtr, as you will see in the patch we can check if authMethods is set to 'password' and grab the password from auth file by calling virAuthGetPassword. regards, david

On Fri, Jun 28, 2013 at 1:03 PM, Michal Novotny <minovotn(a)redhat.com <mailto:minovotn@redhat.com>> wrote: On 06/28/2013 12:28 PM, Peter Krempa wrote: > On 06/27/13 14:31, David Maciejak wrote: >> Hi, >> >> I was discussing with Daniel about the best way to pass the ssh password >> when using such kind of uri: >> 'xen+libssh2://root@192.168.0.10?sshauth=password <http://root@192.168.0.10?sshauth=password> >> <http://root@192.168.0.10?sshauth=password>' >> >> As it seems passing the password in the uri is not a good option, maybe we >> can grab it from auth conf ? it seems it's not the case as now (tell me >> if i am wrong). > I was planing on doing this stuff, but never managed to finish this. > >> So enclosed a patch to add this feature. >> >> As you can see in virnetclient.c there is no virAuthGetPassword call, so >> the authfile is never used. >> >> The patch enclosed is modifying the function prototype to add >> virConnectPtr parameter (so remote_driver.c virNetClientNewLibSSH2 call >> has to be updated too and the corresponding .h too). >> >> Once we have access to virConnectPtr, as you will see in the patch we >> can check if authMethods is set to 'password' and grab the password from >> auth file by calling virAuthGetPassword. >> >> > please use git format-patch and send-email in the future, it makes > reviewing easier. > > See the attached patch for the review. > > Peter > > > > -- > libvir-list mailing list > libvir-list(a)redhat.com <mailto:libvir-list@redhat.com> > https://www.redhat.com/mailman/listinfo/libvir-list Hi all, Peter, you could have reformatted it for better replies on separate code hunks ;-) Like I did now ;-) Thanks for the review guys. ... I suggest tokenizing it after commas, like I'm doing for my personal projects I agree with Michal, using strstr instead of strcmp has also some drawbacks.

regards, david

On Fri, Jun 28, 2013 at 01:43:44PM +0200, Michal Novotny wrote: > if libvirt doesn't have the tokenizer support yet, it may be a good RFE > as I believe it could be really useful ;-) > > Peter, do you know about anything libvirt supports to tokenize string? We have virStringSplit for tokenizing strings which have a fixed separator. Daniel

On 06/28/2013 01:48 PM, Daniel P. Berrange wrote: > On Fri, Jun 28, 2013 at 01:43:44PM +0200, Michal Novotny wrote: >> if libvirt doesn't have the tokenizer support yet, it may be a good RFE >> as I believe it could be really useful ;-) >> >> Peter, do you know about anything libvirt supports to tokenize string? > We have virStringSplit for tokenizing strings which have a fixed > separator. > > > Daniel That sounds good, however what about splitting the function to 2 separate functions, one accepting the second parameter as the separator, called e.g. virStringSplitBy() and second just calling the first one with the fixed separator? Wouldn't it be better?

Michal

On 06/28/2013 01:54 PM, Peter Krempa wrote: > On 06/28/13 13:50, Michal Novotny wrote: >> On 06/28/2013 01:48 PM, Daniel P. Berrange wrote: >>> On Fri, Jun 28, 2013 at 01:43:44PM +0200, Michal Novotny wrote: >>>> if libvirt doesn't have the tokenizer support yet, it may be a good RFE >>>> as I believe it could be really useful ;-) >>>> >>>> Peter, do you know about anything libvirt supports to tokenize string? >>> We have virStringSplit for tokenizing strings which have a fixed >>> separator. >>> >>> >>> Daniel >> That sounds good, however what about splitting the function to 2 >> separate functions, one accepting the second parameter as the separator, >> called e.g. virStringSplitBy() and second just calling the first one >> with the fixed separator? >> >> Wouldn't it be better? > I think the current state is more than sufficient: > > /** > * virStringSplit: > * @string: a string to split > * @delim: a string which specifies the places at which to split > * the string. The delimiter is not included in any of the resulting > * strings, unless @max_tokens is reached. > * @max_tokens: the maximum number of pieces to split @string into. > * If this is 0, the string is split completely. > * > * Splits a string into a maximum of @max_tokens pieces, using the given > * @delim. If @max_tokens is reached, the remainder of @string is > * appended to the last token. > * > * As a special case, the result of splitting the empty string "" is an empty > * vector, not a vector containing a single string. The reason for this > * special case is that being able to represent a empty vector is typically > * more useful than consistent handling of empty elements. If you do need > * to represent empty elements, you'll need to check for the empty string > * before calling virStringSplit(). > * > * Return value: a newly-allocated NULL-terminated array of strings. Use > * virStringFreeList() to free it. > */ > char **virStringSplit(const char *string, > const char *delim, > size_t max_tokens) Ah, then I misunderstood the "fixed separator" thing ;-) I was thinking the delimiter it fixed. This one looks good ;-) David, you could use virStringSplit() instead ;-)