Dear All,
I am having the Perl script which is using Sudo and it is having a lot of sub programs.
The main task of script is to create create the unix user account and database accounts.
Previous version of platform was Sun Solaris, and now are moving to HP UX.
I am posting this, to know if there are any existing prerequisite or guideline where we can perform sanity check on code.
Or any body is having experience of previous problem and have some suggestion. please share.
Testing is well thought of. Write test cases for plain add, remove and various collision, update cases.
Yes, you are taking the right approach. A few suggestions:
Do enough testing with fake accounts to verify correct operation.
At each step of testing, think of ways to make the script malfunction.
Or find a team member who likes to do testing, likes finding glitches.
Make something simple work first. Then add more capabilities.
Use previous logic from script on Solaris, if the code is available.
Every time the script adds a new account, have it display the results,
such as doing a diff between an old and new password file, or showing
a listing of any new files and directories. That's a kind of sanity check.
Spend time upfront picking and sharpening your tools. Use standard
tools you have on the system to add and delete the various account
types. Use any available standard log files for the processes, to help
verify the computer is doing what you want it to.
Yes, a developer should not test his own stuff!
You deserve pretty code, so indent, tab align, slip in white space to keep things neat. You get paid back in better review, fewer errors and faster fixes. Every time you use a new line or each item, you help track changes in line oriented CM tools like SCCS and diff.
Log like you expect a midnight call when you are on vacation. After years of debugging with bad logging, I am now a fastidious logger and error checker. From first trial run to last is very short, usually, because my code does not go far off the track but I get a nice message and exit. Frame runs in the same log with header and trailer lines and blank lines. Put exact time stamps on all events. It's frustrating to be fixing errors in the wrong log. Put date-time-elements in file names, especially the log. For daemons that run many days, use syslog or start a new log every day. You can have a standard logging routine that saves the integer time() of tomorrow so I can check time() and close the log when necessary, with an old log trailer and the new log with a header.
Dear All,
I am having a script which is using the useradd command to create a new user.
it was working fine in solaris but now in HP UX i am getting a prolem. though almost al the option which are available with command are same.
i am using below options
[-c comment]
[-m [-k skel_dir]]
[-d dir]
[-g group] - Security Groupname
[-G group [, group...]]
[-s shell]
[-k skel_dir]
when the script will run it will add the user in /etc/passwd and first the new created account will in locked status.
below is the code which is used to create a account.
my $pUserID = shift(@_);
my $su;
my $Cmd = $myConfig::Configuration{useradd};
my @CmdArgs = ('-c', 'my Account for ' . $myConfig::Configuration{InstanceName} . ' instance',
'-m', '-d', $myConfig::Configuration{AccountHome}."/".lc($pUserID),
'-g', $myConfig::Configuration{SecurityGroupName},
'-G', 'myscr',
'-s', '/bin/ksh',
'-k', $myConfig::Configuration{AccountHome}."/".$myConfig::Configuration{StdAccountName},lc($pUserID));
$su = Sudo->new(
{
sudo => $myConfig::Configuration{sudo}
,sudo_args => ''
,username => "root"
,program => $Cmd
,program_args => \@CmdArgs
}
when i run it in HP US i get below entry in Passwd file
ARRAY(0x6000000000aca598):x:117:20::/home/ARRAY(0x6000000000aca598):/sbin/sh ARRAY(0x6000000000aca638):x:118:20::/home/ARRAY(0x6000000000aca638):/sbin/sh
can somebody guide me about error.
To unlock the account i have planned to use /usr/lbin/modprpw with -k which is silmilar to passwd -u but no idea what will be outcome.
Please suggest why strange entry in /ect/passwd file and suggestion
Wow, severe corruption. Looks like two lines. Any record of who 117 and 118 were, what group 20 is?
Those ARRAY(hex address) strings are the result of using an array reference as a string.
Regards,
Alister
Aliste, Thank you very much for reply.. previously this was not the case when the code was used on solaris..
now when we are using in HP UX we are getting this issue.
One strange thing is that when i run useradd seperataly there is no issue..
sudo /usr/sbin/useradd -c "ricky" -m -d /home/y012653 -g dac -G oclsascr -s '/bin/ksh' y012653
Can you please help me to understand the how to avoid or where to look to print user name not the hash value in passwd file
---------- Post updated 04-09-13 at 09:08 AM ---------- Previous update was 04-08-13 at 10:51 AM ----------
No reply from any body... it seems very few Perl expert 
I think there is a bug in the HP-UX perl.
Either contact HP support for a Perl patch,
or try to find a work around in the Perl code:
the error happens with lc($pUserID) in the code you posted.
So add an assignment to a new variable
$lcUserID=lc($pUserID);
after the previous assignment of $pUserID, and replace the following references lc($pUserID) by $lcUserID
Hopefully the simpler reference will avoid the error.
On a good day, you can avoid host-specific code by using the right tools where there is a redundant set, including commands you can spawn from perl.
In fact, if you find something that is very different, you might be able to script it differently on each machine, and not have the difference invade code that needs that answer or service. Think of how much simpler: main script xxxx calls yyyy, and there are two yyyy scripts, one for each os. None of the three scripts has code for the other host, nor any host type checking. Now, the variant file yyyy could be a perl lib or some sort of executable.
Please forget my previous proposal.
I think Alister was very close; the \@CmdArgs does not work.
What happens if you omit the \ i.e.
,program_args => @CmdArgs
?
After using as this.. The result is same
,program_args => @CmdArgs
it is creating the entry in passwd file with array(hash)
Have you tried using perl's tracing and debugging features? They can be extremely helpful in determining where the train is going off the rails.
If you're not familiar with them, start reading the perlrun man page where it documents the -d switch.
Regards,
Alister
You can also watch PERL from the outside using truss/tusc/strace to see what error started the failure.
I haven't used the Sudo module, but the CPAN page of this module mentions that the value of "program_args" is a string. Check the page out:
Sudo - search.cpan.org
When you specify \@CmdArgs, you pass a reference to the array @CmdArgs.
So, I'd think you may want to pass the array converted to a string, like so -
,program_args => join (" ", @CmdArgs)
or maybe this -
,program_args => "@CmdArgs"
Disclaimer: I haven't tested this at all; this is simply from my observation of the CPAN documentation page of this module. Try this suggestion on a Dev box, **NOT** on a Production box.