SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Switching to SuSE from Red Hat 9. Have a "build" script that sets up directories, copies files, and creates specific users. The part of the script that doesn't work on SuSE looks like this (yes, it works on Red Hat):
seems a pretty obtuse way to achieve a simple goal. Surely you can just use the password as a command line parameter?
[code]passwd $1 $2[code]
where did that bizarre file redirection and cat come from? how does that achieve anything more than "echo $2 | passwd --stdin $1" would have in the first place?
Also if this script is creating standard directories in each new users home directory then you mightn't be aware that ususally any directories in /etc/skel/ will be copied to a new users home and set up for them automatically.
Originally posted by acid_kewpie
seems a pretty obtuse way to achieve a simple goal.
Does it? Why?
Quote:
Surely you can just use the password as a command line parameter?
[code]passwd $1 $2[code]
Surely? Did you try? Did it work? Not on my SuSE 9.2 system, and not on the RH 9, either. Maybe it's some sort of preferences or setup issue, but that's what's happening.
Quote:
where did that bizarre file redirection and cat come from? how does that achieve anything more than "echo $2 | passwd --stdin $1" would have in the first place?
Where did it come from? Well - assuming you asked because you are really curious, as opposed to just tossing out an insult - it was part of another script which set a series of passwords from existing files rather than as input parameters, so the cat .. passwd was already known to work; in the case of this present little script, I happened to look at creating the file for that line to read rather than using echo in the line... in short, it was the first thing I tried, and it worked. Why is it any more bizarre than your idea? They both work, on RH9, but not on SuSE 9.2
Since the point of my question was to find one that works on SuSE, if you've got (a non-bizarre) one that works on SuSE, I'd like to see it, please.
Quote:
Also if this script is creating standard directories in each new users home directory then you mightn't be aware that ususally any directories in /etc/skel/ will be copied to a new users home and set up for them automatically.
What does the fact that useradd is (or is not) creating standard directories have to do with whether I might or might not be aware that RH 9's version of useradd copies the skeleton? Since SuSE isn't on your list of distros, you might not be aware that SuSE useradd does not create home directories as its standard behavior.
I appreciate the fact that you responded, but I don't really appreciate your characterizations of "obtuse" and "bizarre", and it's not particularly useful to suggest that "surely" something will work that in fact does not work.
I followed your advice, looked at the example... and it doesn't work.
I did some more research, and it appears that passwd has a little problem in that it sends "password:" before it's really ready to accept input, so it winds up missing one of the passwords sent to it, and the script quits with only one password sent, so nothing is changed. The authors of expect say this is a known problem and the workaround is to put a little pause before sending... but I haven't been able to find the pause command for expect, yet... when I do, I'll let you know - unless that would be too bizarre???
and Bob's yer Onkel - you have changed the password for user "username" to "newpassweird" - of course, you gotta be superuser to do it, but you are, aren't you?
I have had the same problem & frustration in a Samba context (Samba User Scripting) & soon discovered, as you did, that 'passwd' isn't always 'passwd'. Worse, there is no version info. available for most of the ones I examined.
rant Every %%^-^&-*()c#ing %^7*()m m0r-f@$%ing utility should have a version option, preferably '-V' & '--version'. /rant
Now that I have gotten that off my chest, back to the problem. On a whim, I did:
Code:
man -k password
# actually I refined it to:
man -k password |grep '([18]' |sort -k3 |uniq -cf3 \
|sed 's,^ ,,'|less -S~#25
and voila, there was "chpasswd (8) - update password file in batch" -- just what I needed.
Code:
echo <user>:<pass> | chpasswd
worked for me.
Code:
echo $1:$2 | chpasswd
should work for you.
Of course I am running a (Debian based) MEPIS system, so there are no guarantees that "chpasswd" is available in SuSE. After a few false starts, I did a Linux Google on:
chpasswd(8) suse http://www.google.com/linux?q=chpasswd%288%29+suse
which seems to indicate that is is available for you.
Moral
We all know about "RTFM" & "Google is your friend", but it would seem that
"Apropos (man -k) is your friend, too".
Originally posted by archtoad6 I have had the same problem & frustration in a Samba context (Samba User Scripting) & soon discovered, as you did, that 'passwd' isn't always 'passwd'. Worse, there is no version info. available for most of the ones I examined.
rant Every %%^-^&-*()c#ing %^7*()m m0r-f@$%ing utility should have a version option, preferably '-V' & '--version'. /rant
Now that I have gotten that off my chest, back to the problem. On a whim, I did:
Code:
man -k password
# actually I refined it to:
man -k password |grep '([18]' |sort -k3 |uniq -cf3 \
|sed 's,^ ,,'|less -S~#25
and voila, there was "chpasswd (8) - update password file in batch" -- just what I needed.
Code:
echo <user>:<pass> | chpasswd
worked for me.
Code:
echo $1:$2 | chpasswd
should work for you.
Of course I am running a (Debian based) MEPIS system, so there are no guarantees that "chpasswd" is available in SuSE. After a few false starts, I did a Linux Google on:
chpasswd(8) suse http://www.google.com/linux?q=chpasswd%288%29+suse
which seems to indicate that is is available for you.
Moral
We all know about "RTFM" & "Google is your friend", but it would seem that
"Apropos (man -k) is your friend, too".
BTW, what does
Code:
echo $2 > pw
cat pw | passwd --stdin $1
do, that
Code:
echo $2 | passwd --stdin $1
does not?
Looks like chpasswd will work on SuSE 9.2 - thanks! The "expect" workaround already fixed the particular problem, but I'll probably switch to chpasswd the next time I get into the "build" disk (which might not be that long - the client is opening four more stores in the next few months).
The biggest problem with googling and man'ning and whatnot is finding the right combination of keywords, which is also true of RTFM'ing - if you don't look in any given index for the right word or phrase you come up with nothing, or nothing useful (12,578,413 hits doesn't do you much good if you don't find what you're looking for in the first 30 or 40... which is why forums and usenet get hit with these kinds of questions.
In answer to your BTW, which BTW I think I covered in an earlier response to acid_kewpie, it doesn't do anything that the one-liner doesn't do just as well - the reason I used it is that it was the first thing I tried (copied from a similar script) AND IT WORKED. I work in the principle "If it ain't broke, don't fix it", AND IT WORKED. I don't know what the time saving would be in using the one-liner versus my "obtuse" anbd "bizarre" two-liner, but I'm willing to bet that it is totally insignificant in the actual use (which is a few times a week, not hundreds of thousands of times a day) and it therefore "ain't broke". Do I agree that the one-liner is "better"? Sure I do. Did I change the script? Yes, I did. Does it make any difference in how the script works? Not that I can see.
No software is ever "finished", whether it's an operating system or a simple script... if it was, you'd probably be using DOS 1.0 still.
There are ALWAYS pieces of code in any given chunk of software, that don't work - sometimes nobody's ever managed to do something that makes the non-working code execute, sometimes the non-working code doesn't cause any problems that are major enough for someone to bother finding and fixing the code; sometimes it's a major problem and it gets fixed.
There are also - I firmly believe - many times more pieces of code that are "inefficient", and the same conditions apply there. If it works, and its users don't perceive a "problem" because the code uses twethy-three bytes of memory unnecessarily or because it takes an extra 0.017 seconds to execute, well... I'd say it "ain't broke" and there isn't any real point in "fixing" it. If it uses hundreds of thousands of bytes or takes several seconds, or even minutes, then it gets fixed.
Now, if I am looking at code and notice something and think "damn, that's obtuse and bizarre" and I know of a simple way to change it, I will usually simplify it... but I am usually looking at code trying to find something that IS broke, so I'm not looking for code that is merely "o. & b.". Plus, when you're fixing something that IS broke, my feeling is that it's best to change as little as possible, because of the laws of unintended consequences, i.e., that sometimes fixing one thing can break something else.
Whooo... I apologize for the long answer. But, again, many thanks for finding the "ch" in front of passwd!
No apology for length necessary, like so many (don't take offense) "semi-rants", it was very interesting.
I think you have coined a new term "O&B".
I think we are all guilty of it. -- Just yesterday I was reviewing a script I wrote to strip the 4 lines of German header info from a Knoppix packages.txt file & substitute English ones.
If only tail would accept "-n-n" the same as head does. (The regular "-nn" causes them to display only the last/first n lines, adding the '-' makes that all but the first n lines in head.) I used some super O&B construct involving feeding tail a backticked wc to awk pipeline inside an arithmetic expression which subtracted 4 ... It was so bad, I don't even want to try to reconstruct it. It would qualify as "OB&B" -- "obtuse, bizarre, & Byzantine".
Remember Alexander - you don't have to untie the knot to solve the puzzle.
OTOH, Sometimes it's better to U N T I E than to cut...
In my main app I have running code that was written more than twenty years ago and has never ben changed through all the versions, expansions, and enhancements... and - wait for it - IT AIN'T BROKE, so I ain't fixed it. It's ugly, even O&B, but IT WORKS. I wince when I skim by it, but I've resisted the urge to "fix" it. In some cases it was O&B when it was written, and in some it was the only way to do it at the time (think dBASE II on CP/M machines - 64K with two 360K floppies, no hard disk).
And then there are days when I just want to play with my (virtual) marlin spike.
Practical engineers have a pair of contradictory mottoes:
Don't buy what you can build.
Don't build what you can buy.
Which really each contain an unspoken "cheaper" at the end:
Don't buy what you can build cheaper.
Don't build what you can buy cheaper.
As for Alexander, I heard a very similar idea first in the Army, and many other places since:
"When you're up to your ass in alligators, it's kind of hard to remember that your original goal was to drain the swamp." Both get at our tendencies to get bogged down in minute debugging, instead of effective problem solving. Besides, line about Alexander is original. If you quote it elsewhere, please attribute.
longtex's Second Law: You Don't GET What You Don't PAY For. (There's an old saying, "You get what you pay for", but it's wrong - there's been plenty of times I've paid for something and NOT got it.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.