Tue Aug 12 13:36:00 GMT 2003
On this machine (it's domain rather than home which isn't)
$ mkgroup -cl | grep mkgroup_l_d
I'll just add it to the test with the same message, it'll
be repackaged in a minute or two (will post then).
Igor Pechtchanski wrote:
> AFAIU from the mkgroup code, the group value "mkgroup_l_d" is created
> when the current user is a domain user but the utility was called
> without a -d flag. Basically this is meant as a warning that the
> default passwd and group creation didn't get all the relevant
> information (and that things may break because of that). Pierre,
> Corinna, feel free to correct me. Igor
> On Tue, 12 Aug 2003, John Morrison wrote:
>> This is the only reference I can find to mkgroup_l_d;
>> $ grep -rin mkgroup_ *
>> winsup/utils/mkgroup.c:477: printf ("mkgroup_l_d:%s:%u:",
>> print_sids ? put_sid (tg.psid) : "",
>> what does it do (and what should I say when `id -ng` =
>> On Mon, 11 Aug 2003, Pierre A. Humblet wrote:
>>> I am on vacation and using an unsubscribed address from an
>>> internet cafe, hence the personal mail to Igor.
>>> Thereis no other than mkpasswd, mkgroup and mkgroup_l_d.
>>> Checking uid's becomes useless with 1.5, don't bother.
>>>> From: Igor Pechtchanski <email@example.com>
>>>> Date: 2003/08/10 Sun PM 01:20:13 EDT
>>>> To: John Morrison <firstname.lastname@example.org>
>>>> CC: email@example.com
>>>> Subject: Re: [update] base-files
>>>> On Sun, 10 Aug 2003, John Morrison wrote:
>>>>> At last, a new version of base-files to try :)
>>>>> I've also added a test for id -ng = "mkpasswd" or = "mkgroup"
>>>>> along with a message. Hopefully this might cut down on the number
>>>>> of "I have no user" messages :)
>>>> Did you also check for the "mkgroup_l_d" value? There might be
>>>> some more, too -- Pierre would probably know right away; if he
>>>> doesn't chime in, I'll take a look at the code.
>>>>> If there's a similar test I can do for UID "out of range" I'd
>>>>> be happy to add that to.
>>>> I doubt you can check the *current* UID for being out of range, as
>>>> the numeric value returned is already truncated. You could check
>>>> if /etc/passwd contains UID+65536 or UID+131072 (the most common
>>>> case and the next possible one) and issue a warning (with
>>>> instructions to patch up /etc/passwd) in that case...
>>>> FYI, we're working on a set of new tests in cygcheck, and checking
>>>> /etc/passwd and /etc/group planned as one of those tests. If
>>>> there's a way to check whether the UIDs are 16-bit or 32-bit
>>>> (other than checking
>>>> 1.3 vs 1.5, which, now that I think of it, might also work),
>>>> cygcheck could then issue a warning if /etc/passwd contains UIDs >
>>>> One last note: any messages printed from postinstall scripts are
>>>> not seen by the user -- they go directly to setup.log.full. So,
>>>> if you want this to be seen, we better either move this
>>>> functionality to cygcheck, or duplicate it there. Igor
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other binding commitment through
the use of this electronic communication unless it is issued in accordance
with the Experian Limited standard terms and conditions of purchase or
other express written agreement between Experian Limited and the recipient
Experian Limited (registration number 653331)
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
More information about the Cygwin-apps