Username too long error...

[carock]

Sorry that username is too long. MAX is 8 letters

I found a post where someone said edit the wwwacct file and change the line with that in it.

In that code is also a reference to an environment variable
$ENV{'LONGUSERS'}

In which if it does not equal 1 then that message is displayed for usernames longer than 8 characters.

Is there a place I can set that environment variable in WHM? I could not find it. I would rather not modify code if I can help it, as I have to remake modifications each time I upgrade scripts.

Thanks,
Chuck

 

[twhiting9275]

The reason that is there is for your own benefit.
There are still distributions out there that limit the usernames to 8 chars, so for CP to actually allow larger usernames wouldn't be beneficial to that.

In other words:
8 chars is the linux standard I believe for usernames. yeah, there's a few distro's out there that have gone over that limit (rh is one I think, but I don't recall), but it's not really a good thing to do.

 

[carock]

I understand the limit, but I know it's not necesary on my system, nor FreeBSD which is the other O/S we use. I just want a place to turn it off globally without recoding the WHM scripts all the time.

I 'm getting a pretty long list of mods I have to do each time I run the upgrade. I would think since this is a global environment variable, there should be a switch somewhere.

None of the O/S's we run here have had the 8 character limit for a couple of years. I think it's a safe bet that there are many of the WHM/Cpanel customers that don't need or want an 8 character limit.

Thanks,
Chuck

 

[CrazyNetworks]

OK, I HAVE THIS FIXED


In /scripts/wwwacct on line 343 where it says

if ($ENV{'LONGUSERS'} ne "1") {
if (length($user) > 8) { deaderror "Sorry that username is too long. MAX is 8 letters"; }
}

change it to


if ($ENV{'LONGUSERS'} ne "1") {
if (length($user) > 20) { deaderror "Sorry that username is too long. MAX is 20 letters"; }
}

and the max characters is then 20

 

[PWSowner]

That will work, but everytime a cpanel upgrade is done, that file will be overwritten with the original. You'd have to keep making the change, or automate the changes.

 

[dgbaker]

Just chattr wwwacct and it won't get updated.

 

[PWSowner]

I thought about that, but what if someday cpanel actually makes changes to it. The changes may be needed.

My wwwacct file is customized a bit too. What I do is have a copy of the unedited original file, and a copy of my custom one, wwwacctorig and wwwacctcustom. I have a script set to run 30 minutes after cpanel upgrade runs which compares the real one to each of the others. If it has been restored to it's original, it just copies my custom one back, but if the new file doesn't match the previous original one, it emails me to tell me the original has had changes made to it.

 

[goodmove]

If I changed the length to > 8 in wwwacct, would I be able to upgrade the existing usernames (equal to or < 8) without any problems??

 

[scapeweb]

If I change this and then I upgrade will I have any problems.

Thanks in advance.

 

[carlaron]

This big question is will this break anything else in cpanel? Several OSes can handle longer usernames, but will cpanel get messed up when it finds a long username, or worse yet, two usernames that vary only in the ninth character?

Assuming that we find out it is OK to override this if your Os is OK with it, why change the "8" in wwwacct at all? I think what you want to do is to actually set the environment variable "LONGUSERS" to "yes". That is what the wwwacct script is checking first.... Then the wwwacct, as it is, will ignore the 8 character limit.

Different OSes have different ways to set the environment, but in RH, fo example, you enter a command:

env LONGUSERS=yes

You'd probably want to put this into a startup script somewhere, perhaps the rc.local file.

 

[platypus]

I know this thread is a ghost town, but I couldn't get this last solution to work. The code in the wwwacct script checks to see if LONGUSERS should equal 1, not "yes", right? I did a 'env LONGUSERS=1' command, and entered the same into /etc/rc.local so it will remain active, but no dice, I still get the error. Do I need quotes around the "1" ?

Thanks!

 

[platypus]

The issue seems to be that the environment variable is not "sticking" in the first place. I'm logged into root via ssh and I type:

env LONGUSERS=1

or

env LONGUSERS="1"

Then if I type "env" again to show the variables, LONGUSERS is nowhere to be found. I'm running Redhat 9 Enterprise. Any ideas? Thanks!

 

[mr.wonderful]

When you copy accounts from a Ensim server Cpanel does not handle the long usernames properly. Go figure.

 

[danson]

Yeah i tried this with rc.local as well but no go.

What I was thinking was...shouldn't this actually go into the startup file for whatever user cpanel runs as?

I don't now what this would be though
.profile?
.bash_rs?
.bash_login?

Does cpanel even use bash? =)

At the moment I have just hacked the code to set LONGUSERS to 1 just before the test.


Daniel

 

[platypus]

Yeah, but I would really rather avoid editing this file altogether, since it would seem that the programmers checked this environment variable just so that we could easily tweak the behavior without editing the source (and therefore have to do it again and again whenever cPanel is updated).

My problem is, I can't even get the environment variable to take hold, it doesn't seem to be remembered. I should be able to set the variable, then possibly restart cpanel, then add my longuser accounts.

Does cPanel have an official answer to this? Hello?

 

[danson]

I believe the reason for this is that env actually is ment to be used like:

env [variable=value] commandtorun

Then for the duration that commandtorun is alive it uses the current environment WITH the new variable as set.

when you just do env longusers=1 it just prints out env with the longusers set. After it exits the envronment reverts to normal.

What we need is for the environment of the user that runs cpanel to have longusers hardcoded into their profile. OR perhaps have the init script for cpanel call it with "env LONGUSERS=1" prepended to the command.
This would be somewhere in /etc/init.d/cpanel i guess.

OR you move /etc/init.d/cpanel to say /usr/local/cpanel and replace it with a file which just says:

#!/bin/sh
env LONGUSERS=1 /usr/local/cpanel

 

[platypus]

Oh ok, that helps to explain it. I guess there is a difference between "env" and "set", which seems to be Bash-specific. When you run "env" it prints out a lot of variables that are in use... so I wonder... where were these variables set, and what was its 'commandtorun' that allowed them to remain in use? Maybe that is the file I should be editing, so that LONGUSERS gets set at the same time as USERNAME or HOME. Right?

 

[danson]

We really need an expert on this...

Yes exactly.

However it is easy to forget that when you log in via ssh you are actually INSIDE a running program. Namely bash.

Those variables are actually the environment variables specific to your bash session. Some of them will be set in your user-specific profile and some in the global files which affect all users. I think rc.init is one of them.

I do not know enough about how cpanel/whm runs however to figure out how to get the environment of cpanel changed.

I do have a cpanel user on my system...perhaps if we created some sort of .profile file in it's home directory (/usr/local/cpanel for me) we could modify it's environment?

Experts - your input please!!!

 

[platypus]

Well I guess the environment variables for bash aren't what we want to edit anyways, but rather those for cPanel. So, we need to find where cPanel is started and then run it via ENV, right?

Is it possible to add the environment variable while cPanel is running? Or can we do something like:

/etc/rc.d/init.d/cpanel stop
env LONGUSERS=1 "/etc/rc.d/init.d/cpanel start"

That way we don't need to worry about the machine *booting* with LONGUSERS set. After all, we're not going to be rebooting very often (hopefully) so we could just do these two things before any time when we need to add a new user.

Would that work? Or is it risky due to other parts of the system using that environment variable? Is there an easy way to scan cPanel's files for any references?

If I do

env LONGUSERS=1 "/etc/rc.d/init.d/cpanel start"

and "cpanel" is just a shell script that runs a bunch of stuff, does our modified environment get applied to all those processes that are part of "cpanel start"?

I'm afraid of trying this myself. Haha. What do you think, would it work?

 

[danson]

IT WORKS

Well I wasn't too scared to try because my server is brand new =) and it works!



=====================================
root@fs1 [/sbin]# /etc/init.d/cpanel stop
...
root@fs1 [/sbin]# env LONGUSERS=1 /etc/init.d/cpanel start
Starting eximstats: [ OK ]
Starting cPanel services: [ OK ]
Starting cPanel Log services: [ OK ]
Starting pop3 services: [ OK ]
Starting cPanel Chat services: [ OK ]
Starting Melange Chat services: [ OK ]
Starting cPanel ssl services: [ OK ]
Starting mailman services: Starting Mailman's master qrunner.
=======================================

However env LONGUSERS=1 /sbin/service cpanel start doesn't work nicely.

So now all you need to do is do a fake "cpanel" script in init.d which just has :

#!/bin/sh/
env LONGUSERS=1 /PATH/realcpanel

Should work a treat...


As for safety - all you're doing is setting an environment variable which the cpanel programmers have ALREADY made allowances for. I don't think this will cause problems.

The only fiddly bit is it might be bad to move cpanel out of /etc/init.d (relative paths??) ... but if you leave it in there it'll get executed wrongly.

Maybe write a file zzzcpanelrestart which will then be executed last and which stops and starts cpanel with the environment var using a script somewhere else.