On 11/28/2016 12:32 PM, Gene Heskett wrote: > On Monday 28 November 2016 11:04:10 Mark wrote: > >> The X daemon should start at boot, not when you log in. It needs to >> be listening at the port before you log in to be able to start the >> window manager if you are logging in locally. > So X is running when the login panel is on-screen?
Yep. >>>> I'm confused. What rc.local script gives you full sudo rights? >>> AIUI rc.local runs before the login, > at least it did on the odroid64. It should run at boot, as it's a boot script. If it starts a daemon, the daemon should be monitored and restarted if it stops. > >>> so effectively has root rights >>> and can easily brick the install. But that nobody logged in state is >>> the only time one can play with passwd's, groups and who owns what. >>> But despite composing the script on the raspi exactly the same as >>> worked on the droid, it refuses to execute with the usual ". /fixme" >>> syntax in rc.local. Something about a compatibility issue is logged >>> to the screen and is covered nearly as soon as I log in. With no >>> mouse support, I can't scroll back to copy/paste it someplace less >>> volatile. >> rc.local scripts are boot scripts, not login scripts. > I know that. They run, if they'll run, before the login screen is > presented. No, they run at boot time. Usually long before the login screen is presented. Look at where, in the runlevel inits they actually run. > >> You're probably >> thinking of the .bashrc and .profile files in your home directory, and >> the rc files like bash.bashrc and csh.cshrc files located in the /etc >> directory. > None of the /home/user/* are available to the system until you are logged > in, and then you cannot play with those files in wholesale renaming > quantities. Exactly. Your rc scripts (not to be confused with the rc.local stuff) set up your environment. The /etc scripts set a basic environment, depending on what shell you are using, systemwide. > > Here is that script as it sits on the r-pi: > ======= > #!/bin/bash > OLD_NAME=pi > NEW_NAME=gene > usermod -l $NEW_NAME $OLD_NAME > groupmod -n $NEW_NAME $OLD_NAME > mv /home/$OLD_NAME /home/NEW_NAME > usermod -d /home/$NEW_NAME $NEW_NAME > chown -R $NEW_NAME:$NEW_NAME /home/$NEW_NAME > ========== > and that line in rc.local > . /fixme > > When it ran on the droid, it left $me with a /home/gene directory as copy > of skel, but that was no loss as I hadn't stored anything un-recoverable > there and I am now user 1000 on the droid. > > After it refused to run I mv'd it so it wouldn't try again until I was > sure it would run. But I have no clue why it didn't. Your mv line is missing a $ in front of the "NEW_NAME" for one. That script should only be run once, are you trying to run it more often? Not quite sure why that has to be run at boot time. That's purely an admin script. >>> >>> >> Your hosts file is missing some important entries. >> >> 127.0.0.1 localhost > It is there, top line. I wanted that separated so there was NO confusion. > All thru my systems, 127.0.0.1 is only localhost. That was my bad, I'd forgotten that line popped up from the grep utility, not a complete reading of the hosts file. >> and your FQDN line doesn't list raspberrypi as an alias. Resolving >> raspberrypi to an IP address comes from reading the hosts file, not >> the hostname. > Added the 2nd alias, error gone, thanks. I was not aware one could spec > more than one alias in the hosts file! Only been an exclusive linux > house here since late 1998. :( No worries. Simple things like that are easy to miss. > >> In all the years I admin'ed Linux systems at work and at home, I've >> used either the Synaptic package manager GUI or the command line >> apt-get and other associated utilities. Never had the problems you >> mentioned. Using the command line utilities however, does require >> their careful usage. But so does just about any command line utility >> that has the permissions to make changes to the OS and other loaded >> software. You have to be aware of what the software you are >> installing, updating or upgrading is actually doing. > apt-get has apparently been superceded by apt, although apt-get still > works. Both the droid and the r-pi can use just apt. Apt is the "mother" package. apt-get is a specialized subset of the overall apt program. If you really want to get down to the nitty-gritty, dpkg and it's associated utilities are another way about it. > > After 18 years of linux, I'd like to think I do. > > I think I'll see if a ">/logfile_name 2>&1" appended to that line in > rc.local will get me a non-volatile error log of the attempt to run that > fixme script. Why are you trying to run that script at every boot? Those commands you've placed inside that script are usually used in a one-shot run. Once those commands are run, the old values should not exist anymore. That script will probably break and exit right after the first usermod on subsequent attempts to run the script, since the OLD_NAME=pi will not exist anymore in the /etc/password, /etc/group and /etc/shadow files. > > Cheers Mark, Gene Heskett Cheers, Mark ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
