I am developing an application in beaglebone.
I want to add start up scripts to my Beaglebone but I can not find /etc/inittab.
I am using the image : Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.06.18.img.xz
I think in the previous versions of image there is /etc/initab but for the new distributions I could not find the inittab :/
I want to apply this : Automatic login on Angstrom Linux
but I can not because there is no /etc/inittab.
Where is the inittab in new distributions.
When I write uname -r it gives:
3.2.23
Regards
inittab has been replaced by systemd
This is how I did it for the serial console. You can probably adapt it easily for tty1 by replacing "serial-getty#..." by "getty#...", but I haven't tested it.
cp /lib/systemd/system/serial-getty#.service /etc/systemd/system/autologin#.service
rm /etc/systemd/system/getty.target.wants/serial-getty#ttyO0.service
ln -s /etc/systemd/system/autologin#.service /etc/systemd/system/getty.target.wants/serial-getty#ttyO0.service
Create the following script file in any location (/home/root/autologin.sh in my case)
#!/bin/sh
exec /bin/login -f root
Make it executable
chmod a+x autologin.sh
Edit /etc/systemd/system/autologin#.service and update the ExecStart command by adding the -n (Do not prompt the user for a login name) and -l (Invoke the specified login_program instead of /bin/login) options.
ExecStart=-/sbin/agetty -n -l /home/root/autologin.sh -s %I 115200
Related
I'm trying to set up my system so that when a user logs in, a tmux session will automatically be created for them, and this session is restarted if it ever exits, and the session starts in the user's home directory. I would like this to work for any user, or any new user added to the system, without a static unit file for each user. I'm having trouble making this work in a generic way, because I need to specify User and WorkingDirectory in the unit file for the tmux session to be created for the correct user in the correct directory.
So far my unit file looks like the following:
/etc/systemd/system/tmux-session-service.service...
---------------------------------------------------
[Unit]
Description=Tmux Session Service
[Service]
Type=forking
User=my-user
WorkingDirectory=/home/my-user
ExecStart=/usr/bin/tmux new-session -s tmux-session-service -d
ExecStop=/usr/bin/tmux kill-session -t tmux-session-service
Restart=on-failure
[Install]
WantedBy=multi-user.target
When I install and enable this, everything works like I expect as long as I am logged is as my-user. However if I log in as another user, the tmux session isn't created with the right permissions or working directory for the new user.
I looked into template files, but I can't quite get things to work. I tried setting the target to default.target, and using the %u template directive, but that seems to just refer to the user running the service manager, which is root.
One option would be to run systemctl run tmux-session-service#new-user.service when new-user logs in. Then I could use %i in the User and WorkingDirectory directives in the unit file. But then I need some process that has systemctl permissions to kick that off on user login, and I can't think of a way to do that.
I'm running:
Arch Linux
tmux v3.1c
systemd v247
Under Ubuntu, I install the ....service file under:
/usr/lib/systemd/user/...
With the Debian packager, that is not automatic if you installed using the .service in the debian installation folder. Instead, you have to do it manually so it goes in the correct folder. So say you have a project defined like so:
tmux-session-service/debian/tmux-session-service.docs
tmux-session-service/debian/tmux-session-service.install
tmux-session-service/debian/tmux-session-service.service <-- wrong!
Then for each user I would enable the service like so:
# Make sure the target folder exists
mkdir -p /home/${USER}/.config/systemd/user/default.target.wants
# If you're root when doing that, you want to fix the ownership
# (for the group, you may need a different variable)
chown -R ${USER}:${USER} /home/${USER}/.config/systemd
# If already installed, remove the link before re-creating it
rm -f /home/${USER}/.config/systemd/user/default.target.wants/${SERVICE}.service
# Again, I do this as root, so I need to use special care to run the
# following command as $USER isntead
sudo -H -u ${USER} sh -c "ln -s /usr/lib/systemd/user/${SERVICE}.service /home/${USER}/.config/systemd/user/default.target.wants/${SERVICE}.service"
If you want (can) do it manually, then install the file under /usr/lib/systemd/user/... as mentioned above, and then use the enable option:
systemctl --user enable ${SERVICE}.service
The problem with this technique is that you need to log in as each user to order to enable your service.
I think there is a way to have a service auto-start for all users, but that I haven't found out how to make it work yet...
Could it be as simple as putting something in new user's .bashrc files (or in the /etc/profile file to get a system wide effect) that attaches to a tmux session called 'main' (this would create it if it doesn't already exist)?
That's what I have in mine, and it's as if tmux is just a built in feature of my terminal:
# Launch tmux
if command -v tmux>/dev/null; then
[[ ! $TERM =~ screen ]] && [ -z $TMUX ] && tmux new-session -A -s main
fi
I'm trying to connect to my vpn on startup. I normally enter protonvpn c -f into command line.
I have tried the method of creating an rc.local file however it didn't work.
This is the code I have inside of it (I got this from a post about a similar issue):
#!/bin/sh -e
/usr/local/bin/protonvpn c CH-NL#1
exit 0
I also made the file executable with chmod +x.
Im running Kali 2020.1 if that helps.
How do I fix this?
create a file ==> /etc/rc.local
Open and Edit rc.local like below,
replace your command with apt-get update below
#!/bin/sh -e
apt-get update
exit 0
save the edit with Crtl+X
after that
sudo chmod +x /etc/rc.local
then do a reboot and check
It should 100% work like a charm
This solution should work for ubuntu systems.
https://askubuntu.com/a/290107/1051584
Kali is debian based so I believe this will probably work as well.
I have a script that needs to mount a Windows share to a Linux box, run a script, then unmount it. Despite following the man page for mount.cifs the command fails to recognize the credential file.
I made sure file sharing packages were present:
sudo yum install samba-client samba-common cifs-utils
Created drive that network share will mount to
sudo mkdir /share/
Created the credential file
sudo vim /root/.cifs
.cifs file contents
username=uname
password=pword
Created my .sh file
sudo vim /usr/bin/scritp.sh
script.sh contents
#!bin/bash
mount.cifs //ipaddress/share /share/ -o credentials=/root/.cifs
<script which makes use of the share>
umount /share/
Made the script executable
sudo chmod u+x /usr/bin/script.sh
Tested script
cd /usr/bin
sudo ./script.sh
Despite having the credential file specified, I am still prompted for a password for root user (connecting to Windows share with no "root" user"
Output from running script:
Password for root#//ipaddress/share:
Can anyone figure out what I have done wrong? It seems consistent with all documentation I have read.
For some reason, modifying the script to the following worked:
mount -t cifs -o credentials=/root/.cifs //ipaddress/share /share/
cd /share/
./script.sh
umount /share/
Not sure why, since mount -t cifs just invokes mount.cifs, but if you are experiencing the same issue, that's how I finally got around it.
I am trying to make cgMiner auto-start when my Raspberry Pi (Raspbian Linux) starts.
Edited the rc.local file:
sudo nano /etc/rc.local
and added this line:
nohup ./cgminer-3.1.1/cgminer --config /home/pi/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 >/dev/null 2>&1&
and cgMiner doesn't start. If I type in terminal the exact same line with sudo in front it works perfectly.
sudo nohup ./cgminer-3.1.1/cgminer --config /home/pi/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 >/dev/null 2>&1&
What can I do?
I think it is related to the path or better the current working directory.
You are using ./cgminer and not a full path. So either use the full path or first cd to the directory containing the cgminer program.
Also have a look at the following page over at adafruit doing the exact same thing you are trying to accomplish
http://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/configure-auto-start
Adafruit has the following code in /etc/rc.local
cd /home/pi/PiMiner
python PiMiner.py &
cd ..
nohup ./cgminer-3.1.1/cgminer --config /home/pi/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 >/dev/null 2>&1&
The first and third line (the cd commands) ensure that the folder containing the folder containing the cgminer command is the current directory.
From the two cd commands adding the following command before the line containing the cgminer command would solve your issue
cd /home/pi
I seem to have found the solution for this problem, assuming it is the same as for bfgminer.
After spending a full day playing with init.d scripts, I found the simplest way is to make sure your cgminier.conf file has all the arguments in then add the following to the end of /etc/rc.local
cd /home/YOURNAME/bfgminer
sudo ./bfgminer
It ran without the sudo part, but didn't start up my block erupter without it.
I also managed to get it running from init.d, but had issues with it preventing system rebooting when done that way.
Hope that helps
I configured cygwin in Windows Server 2008, now we need to implement automation
I am writing a batch script to add user to cygwin\etc\passwd file using following command
mkpasswd -l -u %username% -p /home >> /etc/passwd
Please help me how to execute following cmd in batch file
echo off
C:
chdir C:\cygwin\bin
bash --login -i
mkpasswd -l -u %username% -p /home >> /etc/passwd
It's not working
You're mixing Windows and Unix in your windows batch file. The batch file is running as a Windows command, as is the mkpasswd command in it. Windows has no concept of /etc/passwd and will throw an error. Probably something like;
D:\cygwin\bin>mkpasswd -l -u testusr -p /home >> /etc/passwd
The system cannot find the path specified.
Given what you want to do with mkpasswd I'd suggest you find a way to run your automation from within Cygwin. Perhaps setting up a cron job.