Hello Andrew!

Saturday July 18 2015 13:26, you wrote to me:

 > I think this is Mageia related; when I have some spare time and a
 > machine to try it, I will do a test setup and see what I can figure
 > out.

Please Andrew as I have run out of options :)

Yesterday I noticed that the /etc/shadow file is read only for owner (root) 
and
group and changed it to write for owner but made not the slightest difference
->

Then re-installed telnetd and client to create a new user coenvb.

In the debug log I show

-------------------
  18-Jul-2015 18:01:00 mbnewusr[5233]
  18-Jul-2015 18:01:00 mbnewusr[5233] MBNEWUSR v1.0.4
+ 18-Jul-2015 18:01:00 mbnewusr[5233] TERM=xterm 80x43
+ 18-Jul-2015 18:01:00 mbnewusr[5233] GeoIP location: N/A, -- --
+ 18-Jul-2015 18:01:05 mbnewusr[5233] Newuser registration
+ 18-Jul-2015 18:01:16 mbnewusr[5233] Name entered: Brian Coen
+ 18-Jul-2015 18:01:23 mbnewusr[5233] NameGen(Brian Coen)
p 18-Jul-2015 18:01:32 mbtask[3725] Ping: timeout to 81.179.6.57
+ 18-Jul-2015 18:01:36 mbnewusr[5233] Execute: /home/mbse/bin/mbuseradd 503
coenvb Brian Coen /home/mbse/home
+ 18-Jul-2015 18:01:37 mbnewusr[5233] Execute: /home/mbse/bin/mbpasswd coenvb
test1
? 18-Jul-2015 18:01:37 mbnewusr[5233] Execute: returned error 5
? 18-Jul-2015 18:01:38 mbnewusr[5233] Failed to set unix password
- 18-Jul-2015 18:01:38 mbtask[3725] Unregistered client pgm "mbnewusr", pid
5233, slot 1, mailers 0, TCP/IP 0
p 18-Jul-2015 18:02:12 mbtask[3725] Ping: timeout to 81.179.6.57
p 18-Jul-2015 18:03:06 mbtask[3725] last message repeated 2 times
-------------------

As a note, UID (user id) 503 is mbse.

I am a little iffy about that error number eg, 5 = busy.

As a side note:  I have forgotten if this issue came about only after I
switched where it is installed e.g., to /home/mbse instead of /opt.

That said, having being involved as a professional System tester as well as
test manager etc, I hope I would have noticed the fault after changing
location.

There is no logical reason for the problem with MBNEWUSR to be breaking just
because of that change as it is playing with files in /etc.

The way it does it by directly changing the shadow file in not consistant with
Linux practices for security and really should be using the system supplied
program functions.

If memory serves it does use the correct system functions to create the 
account
but instead of adding the new users password at that time does it after
creating the account.  I did hack the code to create a password at new user
create to see if it barfed but I think that worked. However the user could 
want
to change the pw at any time and the same code is used as that that is having
the problem so hardly a solution other than for a simple test :(



Vince

--- Mageia Linux v4/Mbse v1.0.4/GoldED+/LNX 1.1.5-b20130910