Looks like it will lead to confusion if we allow the account to be defined at the target level. May be we should define the account (account name and password) at the global level and have just the "association" at the target level, what do you think ? On Tue, 2010-03-02 at 00:19 +0100, Tomasz Chmielewski wrote: > On 01.03.2010 23:44, Chandra Seetharaman wrote: > > >> I wrongly assumed that if users will be used, they will be different for > >> each target. > >> This is because we can't add another user with the same name; there is > >> also (I think?) no way to change user password without removing the user > >> and adding it again. > > > > Yes, that is true w.r.t the current tgtadm interface. Do you think we > > should add an interface to change only the password ? > > Yep, I think it would be better to just pass a new password when the > user is there (which would update this setting for all targets using > this username); removing the user, adding it with a new password, and > re-adding it to all targets which had it previously complicates it a bit. > > > >> So removing the user before it's added sounded like a good way to handle it. > >> > >> The fix would be to check what users each target have and only > >> remove/update the user when needed. > >> Note that it will be still impossible to have two targets with the same > >> users, but using a different password. > >> > > > > So, you are planning to check if the user name is previously defined, if > > so, make sure the password is same and proceed without adding ? > > I want to check if the user is there - if it is there, then don't remove > it / don't create it with a (possibly) different password. > > Something like this. Which too may lead to some confusions (i.e. > updating targets). > So setting a new user password with tgtadm would be best. > > > > Just fail tgt-admin when tgtadm of account creation fails ? > > If tgtadm fails, tgt-admin would fail, too. > > But if we wanted to create a user for each target (even if the user is > the same), this would be bad, too (as it would be impossible to use the > same user for multiple targets). > > -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
