Re: [Setup-tool-hackers] users-admin has trouble with groups,empty lists



Thus spake Tambet Ingo:
> Hello, and thanks for Your report.

Thanks for your (prompt, patient and detailed!) reply!

> > If `Show all users and groups' is unchecked, then by default (on my
> > system) NO groups show up.
> > This is because RedHat defaults to making the `users' group 100, and
> > all other groups under about 250.
> > However, many packages create groups between 100 and 500
> > (pppusers, popusers, xfs, wine -- just for starters!)
> 
> The distiction between normal and system users is done considering
> variables from /etc/login.defs file (UID_MIN, UID_MAX, GID_MIN,
> GID_MAX). I consider all those groups You listed system groups, cause
> there's no real user behind them.

okay, got it -- I was confused about this...
It seems that it's not possible to change the `Default' profile,
right? (in fact, the profiles dialog is kinda buggy -- i'll write up
some reports later...)

> RedHat defaults to make new group to every user

was this always the case? I seem to remember new users having group
`users', but maybe that was me unconsciously setting it.

> > If `show all users and groups' is unchecked (as it always is for `fewer
> > options'), then on a default RedHat installation (5.2,6.x,7.x at
> > least...), `User Settings...' throws:
> > 
> > Gtk-CRITICAL **: file gtkcombo.c: line 849 (gtk_combo_set_popdown_strings): assertion `strings != NULL' failed.
> 
> That is a bug. But with default redhat You really should have at least
> one group which is named after Your username.

Got it -- though it might be a problem for people who've moved from
other/older distros? (or maybe all distros have defaulted to making a
new group per user for a while?)


> > The `Add group...' and `Groups/Settings...' dialogs are missing
> > a key feature: GID!
> > `Add' should set a default GID (starting at 500, say) (not displayed
> > on `fewer options'), and the GID should be editable through
> > `Settings...'
> 
> That's what is happening. 'Add' adds new group with first available GID
> starting from GID_MIN. But yes, Advanced mode should have GID entry as
> well. For now You can edit GIDs inline in Groups list (adv mode only).
> 

Aha!
If there is at least one group at or above GID_MIN, then it works, but
if there are NO groups at/above GID_MIN, then the first new group has
no GID set (and if you add more groups, they too won't have a GID
set).

> > The default group for new users should be `users', not themselves.
> > Think of the following case:
> > J. Newbie creates two users: foo, bar
> > There are now 2 users, and 2 groups.
> > However, foo can be a member of foo and bar and bar can be a member of
> > bar and foo.
> > What are these `group' things again???
> > Otoh if there's just one group, users, to which everyone is added,
> > this doesn't arise.
> 
> Most of distros behave like RH, giving new group for every user. I think
> we should follow that trend and be consistent with others...

okay, got it.

> > Why aren't the `Group' and `Comment' columns shown in the `more
> > options' user scrollbox???
> 
> What do You mean by 'user scrollbox'? Main window's user listing?

yup -- didn't know what to call it...

> If that's the case then You can add/remove/ columns, sort/group by columns
> etc... To do that right-click on table header and popup menu appears
> with all these options. Note that Your designed table layouts get saved
> through sessions.

oh cool...
er, is there any way of providing a more visible interface for this
(say, a menubar with `Settings' and `Help', for those of us who like
menubars/words?)

Also, I now get more bug reporting to do!
(more serious bug delimited by *****):

In the main window's user listing column headers context menu
<catch breath/>, the `Unsort' item should be called `Unsort/ungroup',
since it also cancels grouping.

The sort arrows are kinda confusing -- I understand `up = ascending,
down = descending', but the problem is when the arrow points up, the
entries of the column increase DOWN...and it feels like it should be
the reverse (where are GNOME UI guidelines when you need them?).

In: `Customize Current View...'

  The `Customize Current View' dialog should be tabbed, not just having
  3 buttons that pop up yet more dialogs.
  Also, it should have a real name (the window title is just
  `users-admin', while it should be `Customize Current View' or
  something...)

*****
  The `Show Fields...' subdialog is broken -- both lists of fields
  display: `[custom widget creation failed]' and STDOUT/STDERR shows:
** WARNING **: could not find widget creation function
*****

*****
  The `Group items by...' subdialog allows one to set sort order,
  which works fine.
  However, when grouping is on, clicking on the column by which one
  is grouping changes the sort order ARROW, but doesn't change the
  sort order.
*****

Also, when one is sorting/grouping by multiple columns, the UI gets a
little confused/confusing (this is kinda minor, since it'll inevitably
be a bit confusing, and someone who's changing the sorting/grouping
around will prolly have the `Customize current view...' dialog open):
  
  One can click on a column to change the sort order, but if you click
  on it so that it becomes unsorted, all lower levels of sorting are
  nuked (e.g., if I sort by group then username, then stop sorting by
  group, it'll also stop sorting by username) -- it would be better if
  it kept sorting by lower levels (in the e.g., it should keep sorting
  by username).

  There's no way to tell just from looking at the columns which
  sorting/grouping is being done first (i.e., one just sees lots of
  arrows). This isn't such a problem for grouping, since they are
  displayed in the user listing, but it's a bit confusing for sorting
  -- maybe to the right of the arrow, one could have a number (1 2 3
  4) for where it is in the sorting order (only when there's more than
  one sort, clearly)?

*****
  Multi-level grouping is broken:
  Try grouping by `shell' then `home' (for instance -- or `group' then
  `shell', or whatever) -- the group headings are correctly
  displayed/counted, but within each subgroup, you get ALL users.
  No clue what's causing this.
*****

> > In the `User settings' dialog:
> > 
> > the use of `$user' is likely confusing to anyone who's not familiar
> > with shell variables -- it would be better to instead include the
> > user's name (yes, this would mean updating the default home directory
> > whenever the admin changed the username -- it should be clear to them
> > what's going on, since they are both visible at once).
> 
> I don't think it's confusing. It's for advanced mode and everyone who's
> even little bit advanced should know about variables (in our case $var
> is variable in both shell and perl). It's like that in Windows also so
> it shouln't be confusing for windows users either.

Okay -- I guess this won't be such a concern when there's some `Help'.
(Does windows now use $ to indicate variables? Last I checked it used
% but that was many years ago, and I wouldn't count on them being
consistent)


> >   Password tab:
> > 
> >     The `Enter a new password' button is gratuitous: just include two
> >     boxes (enter password, confirm (`confirm' greyed by default)).
> 
> Yes. I didn't get it ready for 0.4 release and it's not checked in yet.
> Will be very soon though.

cool...

> >     Actually, in the `add user druid' there shouldn't be a checkbox --
> >     it should require that the password be of good quality
> >     (if you need a druid to add a user, you need to be prevented from
> >     setting your password equal to your username)
> 
> We do the checking using libcrack and if user doesn't have it installed
> then it's kinda hard to check it's quality.

Okay -- then if libcrack is not installed, it should not check the
quality, and if libcrack is installed, it should check the quality,
all without offering a checkbox to the newbie.

> So if the user doesn't have
> libcrack installed, there isn't that checkbox (Actually it is but it is
> known bug :)

Hmmm...I/we've mentioned several bugs above -- should these be put in
bugzilla so they don't get lost, as this is kinda lengthy?
(I could do this...)

-- 
  -nils
Public key: http://www.nbarth.net/~nbarth/pub-key.txt
http://www.sneakemail.com/   ** Free disposable email addresses!

PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]