On 12/27/2016 08:59 AM, John Fawcett wrote:
> On 12/27/2016 12:17 AM, G. Schlisio wrote:
>>> I managed to find where this is happening. It is not in glibc but in
>>> systemd.
>>>
>>> If your /etc/nsswitch.conf has something like this:
>>>
>>> passwd: compat mymachines systemd
>>>
>>> then the r
On 12/27/2016 12:17 AM, G. Schlisio wrote:
>> I managed to find where this is happening. It is not in glibc but in
>> systemd.
>>
>> If your /etc/nsswitch.conf has something like this:
>>
>> passwd: compat mymachines systemd
>>
>> then the routines that are being used are systemd ones.
>>
>> Th
> I managed to find where this is happening. It is not in glibc but in
> systemd.
>
> If your /etc/nsswitch.conf has something like this:
>
> passwd: compat mymachines systemd
>
> then the routines that are being used are systemd ones.
>
> The checks being done are here in the function vali
On 12/25/2016 07:40 PM, John Fawcett wrote:
> Hi Georg
> thanks for that, so at least we have consistent behaviour which is good.
> I had got the from your logging without realizing it was
> anonymized.
>
> Now the problem to solve is why the user names you are testing with give
> the inva
On 12/25/2016 06:30 PM, G. Schlisio wrote:
>> I tried that on archlinux. The above program still produces EINVAL for
>> login names between 32 and 255 inclusive.
>>
>> _SC_LOGIN_NAME_MAX is 256 on that platform.
>>
>> John
>>
> hi,
>
> earlier i tried with literal "AA", which was probably not w
>
> I tried that on archlinux. The above program still produces EINVAL for
> login names between 32 and 255 inclusive.
>
> _SC_LOGIN_NAME_MAX is 256 on that platform.
>
> John
>
hi,
earlier i tried with literal "AA", which was probably not what you
meant.
it produced a "not found".
using
On 12/25/2016 05:12 PM, Wietse Venema wrote:
> John Fawcett:
>> for an inexistent user for strings up to 31 chars. From 32 chars onwards
>> instead of returning not found it retuns EINVAL (invalid argument).
>>
>> ./test AAA
>> Not found
>> ./test AAA
John Fawcett:
> for an inexistent user for strings up to 31 chars. From 32 chars onwards
> instead of returning not found it retuns EINVAL (invalid argument).
>
> ./test AAA
> Not found
> ./test
> getpwnam_r: Invalid argument
Perhaps th
On 12/25/2016 11:10 AM, G. Schlisio wrote:
>> Georg
>>
>> I don't think there is enough evidence at the moment to say with
>> certainty that any change in glibc has introduced the problem, since you
>> were using that for a while now without seeing issues.
>>
>> I'd still be interested in knowing w
> Georg
>
> I don't think there is enough evidence at the moment to say with
> certainty that any change in glibc has introduced the problem, since you
> were using that for a while now without seeing issues.
>
> I'd still be interested in knowing what output the test program gives on
> the affec
On 12/24/2016 02:43 PM, G. Schlisio wrote:
>
> Am 24.12.2016 um 08:40 schrieb John Fawcett:
>> On 12/24/2016 01:19 AM, Wietse Venema wrote:
>>> John Fawcett:
>> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
>> /*result/ to /pwd/. If no matching password record was foun
Am 24.12.2016 um 08:40 schrieb John Fawcett:
> On 12/24/2016 01:19 AM, Wietse Venema wrote:
>> John Fawcett:
> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> /*result/ to /pwd/. If no matching password record was found, these
> functions return 0 and store NULL
On 12/24/2016 01:19 AM, Wietse Venema wrote:
> John Fawcett:
"On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
/*result/ to /pwd/. If no matching password record was found, these
functions return 0 and store NULL in /*result/. In case of error, an
error number
John Fawcett:
> >> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> >> /*result/ to /pwd/. If no matching password record was found, these
> >> functions return 0 and store NULL in /*result/. In case of error, an
> >> error number is returned, and NULL is stored in /*result/. "
On 12/23/2016 06:22 PM, G. Schlisio wrote:
>> Georg
>>
>> Replying to my own post: on re-reading the specification, it looks clear
>>
>> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
>> /*result/ to /pwd/. If no matching password record was found, these
>> functions return 0 a
> Georg
>
> Replying to my own post: on re-reading the specification, it looks clear
>
> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> /*result/ to /pwd/. If no matching password record was found, these
> functions return 0 and store NULL in /*result/. In case of error, an
On 12/23/2016 04:29 PM, John Fawcett wrote:
> On 12/23/2016 03:56 PM, G. Schlisio wrote:
>>> It was worth checking the obvious to exclude it.
>>>
>>> I suspect that one of the system libraries used by the .forward
>>> mechanism has been impacted by your upgrade.
>>>
>>> If you don't need to use .fo
On 12/23/2016 03:56 PM, G. Schlisio wrote:
>> It was worth checking the obvious to exclude it.
>>
>> I suspect that one of the system libraries used by the .forward
>> mechanism has been impacted by your upgrade.
>>
>> If you don't need to use .forward files you might try setting
>>
>> forward_path
> It was worth checking the obvious to exclude it.
>
> I suspect that one of the system libraries used by the .forward
> mechanism has been impacted by your upgrade.
>
> If you don't need to use .forward files you might try setting
>
> forward_path =
>
> in main.cf and restart postfix. If that
On 12/23/2016 03:20 PM, G. Schlisio wrote:
> Am 23.12.2016 um 15:11 schrieb John Fawcett:
>> On 12/23/2016 01:56 PM, G. Schlisio wrote:
Couldn't find the postconf -n output at that link
>>> sorry, correct link for postconf -n: http://termbin.com/w509
>> It doesn't look like "local" is even att
Am 23.12.2016 um 15:11 schrieb John Fawcett:
> On 12/23/2016 01:56 PM, G. Schlisio wrote:
>>> Couldn't find the postconf -n output at that link
>> sorry, correct link for postconf -n: http://termbin.com/w509
>
> It doesn't look like "local" is even attempting to open the
> mailbox_transport_maps
On 12/23/2016 01:56 PM, G. Schlisio wrote:
>> Couldn't find the postconf -n output at that link
> sorry, correct link for postconf -n: http://termbin.com/w509
It doesn't look like "local" is even attempting to open the
mailbox_transport_maps file. That's a good indication that the config
file you
> Couldn't find the postconf -n output at that link
sorry, correct link for postconf -n: http://termbin.com/w509
On 12/23/2016 12:34 PM, G. Schlisio wrote:
>> Hi Georg
>>
>> for reporting problems you can refer to
>> http://www.postfix.org/DEBUG_README.html#mail if you have not already
>> seen it.
>>
>> For the configuration, command output from *
>> *
>>
>> *postconf -n*
>>
>> *postconf -Mf*
>>
>> is a good
> Hi Georg
>
> for reporting problems you can refer to
> http://www.postfix.org/DEBUG_README.html#mail if you have not already
> seen it.
>
> For the configuration, command output from *
> *
>
> *postconf -n*
>
> *postconf -Mf*
>
> is a good starting point. Most people post it to the list, bu
On 12/23/2016 10:33 AM, G. Schlisio wrote:
>> Georg
>>
>> probably the best thing is to compare your previous configuration to the
>> new one and see what changed.
>>
>> For help with your current configuration, you should post it.
>>
>> John
> hi john,
>
> thank you for your suggestion. as i tried
>
> Georg
>
> probably the best thing is to compare your previous configuration to the
> new one and see what changed.
>
> For help with your current configuration, you should post it.
>
> John
hi john,
thank you for your suggestion. as i tried to indicate with "no changes
in mail config" th
On 12/23/2016 09:47 AM, G. Schlisio wrote:
> Dear list,
>
> We have a mail server with postfix and dovecot on Archlinux where we
> have mail
> addresses with local unix accounts (authenticated by pam) and without
> unix accounts (dovecot passwd-file authentication). The problem only
> affects those
Dear list,
We have a mail server with postfix and dovecot on Archlinux where we
have mail
addresses with local unix accounts (authenticated by pam) and without
unix accounts (dovecot passwd-file authentication). The problem only
affects those non-unix account mail addresses. (There are also
comple
29 matches
Mail list logo
