I'm using the minimal nixos VM image.
According to: https://nixos.org/nixos/manual/index.html#sec-x11
I just need to add these lines (to /etc/nixos/configuration.nix presumably)
services.xserver.enable = true;
services.xserver.desktopManager.xfce.enable = true;
Once I do a sudo nixos-rebuild switch and install xinit via nix-env -i xinit, and execute startx I get an error of:
hostname: Unknown host
xauth: file /home/demo/.serverauth.2821 does not exist
You don't use xinit to start X in nixOS. To do that, enter systemctl start display-manager.service. But it should start automatically after you reboot your system, so I think something is misconfigured (maybe you have services.xserver.autorun set to false?).
Related
I am not able to run reboot commands on my CentOS 7 machine.
For example I've created a script: /home/usr/myscript.sh (marked executable) with:
echo "hello world" > example.txt
When Im trying to run the script from terminal everything works good.
I tried to start the script on reboot at the end of the file:
nano /etc/crontab
I added:
#reboot /home/usr/myscript.sh
and on restart, nothing happen.
I also tried to edit file:
crontab -e
its looks like a new generated file, I've typed my command, and again nothing happend.
How can I run a command on CentOS at reboot?
I tried to insert that command on my Ubuntu machine, and everything was good and worked properly.
Anyone can advise on different way (maybe 3rd party program) that will help me to manage the reboot jobs?
Thanks for the help.
BTW, its might be duplicate, but I cant find any answer that helped me
In CentOS/RHEL 7, the systemctl utility replaces some older power management commands used in previous versions. The table below compares the older and new equivalent systemctl commands. The old commands listed in the table still exist for compatibility reasons.
Older Command systemctl equivalent Description
halt systemctl halt Halts the system
poweroff systemctl poweroff Powers off the system
reboot systemctl reboot Restarts the system
pm-suspend systemctl suspend Suspends the system
pm-hibernate systemctl hibernate Hibernates the system
pm-suspend-hybrid systemctl hybrid-sleep Hibernates and suspends the system
I was able to reach this out by adding a crontab file for my user.
with the following command:
crontab -u usrname filename
That allow me to run my scripts.
Thanks !
I read docs :
https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox.md
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandbox_ipc.md
But can't figure out the way to have a properly configured sandbox, and no way to find the script update-linux-sandbox.sh on my system.
I've found it here
but I get :
$ ./update-linux-sandbox.sh
/tmp/../out/Debug does not exist. Use "BUILDTYPE=Release ./update-linux-sandbox.sh" If you are building in Release mode
$ BUILDTYPE=Release ./update-linux-sandbox.sh
/tmp/../out/Release does not exist. Use "BUILDTYPE=Release ./update-linux-sandbox.sh" If you are building in Release mode
The only insecure workaround I have is to use :
const browser = await puppeteer.launch(
{headless: true, args: ['--no-sandbox', '--disable-setuid-sandbox']}
);
Any idea to do the things properly ?
For Debian, in my case version 9 Stretch, the problem seems to be related to sandboxing not being turned on. Chromium will spit out the fatal-message:
No usable sandbox!
For a solution until reboot (run from the command-line as root):
echo 1 > /proc/sys/kernel/unprivileged_userns_clone
For a more permanent solution (run from the command-line as root):
echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns.conf
service procps restart
More Debian related info can be found here:
https://www.bountysource.com/issues/48328601-chrome-headless-doesn-t-launch-on-debian
https://superuser.com/questions/1094597/enable-user-namespaces-in-debian-kernel
If you're here looking for a way to run Puppeteer in Centos7 without the --no-sandbox arg then the #MevatlaveKraspek answer won't work
I managed to get Puppeteer taking screenshots without the --no-sandbox flag arg by setting a Linux kernel parameter to enable namespacing (on CentOS Linux release 7.4.1708).
As root user run:
echo "user.max_user_namespaces=15000" >> /etc/sysctl.conf
Check it worked with:
sudo sysctl -a | grep user.max_user_namespaces
Now reboot your system and run a script without using --no-sandbox e.g const browser = await puppeteer.launch();
If it still doesn't work you might be using an older Linux Kernel and will require a couple of extra args set in the Kernel.
As root user run:
grubby --args="user_namespace.enable=1 namespace.unpriv_enable=1" --update-kernel="$(grubby --default-kernel)"
Now reboot your system and check the Kernel command line for the 2 params you just added
cat /proc/cmdline
If they are in the command line run a script without using --no-sandbox again e.g const browser = await puppeteer.launch();
It should work now. If it doesn't you might be using an old kernel which doesn't support namespacing.
You can check your kernel version with:
uname -a
This is my kernel version which I've got Puppeteer running without --no-sandbox arg.
Linux centos7 3.10.0-693.21.1.el7.x86_64
Hope this helps :)
Figured it out : enable user namespace cloning from kernel :
sudo sysctl -w kernel.unprivileged_userns_clone=1
You can try:
As root user run: echo "user.max_user_namespaces=15000" >> /etc/sysctl.conf
Reload sysctl: sysctl -p
I wonder if you can help.
I am running the following versions:
OS: SMP Debian 3.2.81-1 x86_64
uWSGI: uWSGI 2.0.11.2
I installed uWSGI manually, as I want to use a specific version. Using the following commands: -
apt-get install build-essential psmisc python-dev libxml2 libxml2-dev python-setuptools
cd /opt/
wget http://projects.unbit.it/downloads/uwsgi-2.0.11.2.tar.gz
tar -zxvf uwsgi-2.0.11.2.tar.gz
mv uwsgi-2.0.11.2/ uwsgi/
cd uwsgi/
python setup.py install
I am trying to replicate the setup on another server that the project is already working on in a live environment (I am essentially setting up a test server environment).
The original server has uWSGI running on boot. To figure out how this is happening, I used
htops
I've been able to identify that uWSGI is running on the existing server with a set of command line switches. I've managed to track down the script that initialises uWSGI with these switches in the init.d folder.
I copied this script to my test server, and ran it using
service script.sh start
After various troubleshooting, mainly involving permissions on socket folders etc, now when I run this script it starts, and if I run htop I can see uWSGI is running and it has the exact same command switches I need.
I thought simply putting the script in init.d and giving it execute permission
chmod +x script.sh
Would be enough so that it starts when the server is switched on... but this appears to not be the case. Because when I issue
reboot
At the terminal, the terminal reboots but when I go into htops, and check for the uWSGI process it is not running.
If however directly after reboot I issue the following command
service script.sh start
The service starts just fine, and I can once again see it in htops.
Research online lead me to the suggestion that I should try to set the script to run automatically using chkconfig. I installed chkconfig using
apt-get chkconfig
and then ran the following command
chkconfig --list
I noticed that all the runtime levels where set to off for the script I am trying to get to execute on boot.
I ran the following command
chkconfig /etc/init.d/script.sh on
And now when I check the script runtime switches with chkconfig, it shows me the following output for my script:
script.sh 0:off 1:off 2:on 3:on 4:on 5:on 6:off
However when I reboot the uWSGI process is still not starting.
Yet if I simply type
service script.sh start
At the terminal the service runs ok, and uWSGI runs fine.
How can I set the script to run when the server restarts?
Edit:
Further research on the live server that is working fine, has determined that it does not appear to be using systemd to launch uWSGI on startup. I logged into the live server and while there is a
/etc/systemd
folder, it has just one folder in it system and no files. The system folder has the following files in it:
multi-user.target.wants sockets.target.wants syslog.service
So there does not appear to be anything uWSGI related in here.
Also what is making me think this is likely something to do with the
/etc/init.d
folder, is that when I run htop and examine the running services (or daemons) not quite sure of the correct terminology in linux. uWSGI is showing in here as running with a signature of command line switches, and the script I have found in /etc/init.d has this exact uWSGI command and same signature of switches, so I'm fairly convinced this is the part of the system that is starting the uWSGI daemon , I just can't figure out what I need to do , to get it to run apart from copying the same file to /etc/init.d on the new server and giving it execute permission.
The OS of the live server is :
SMP Debian 3.2.73-2+deb7u1 x86_64
and the OS I am running on the new server is
SMP Debian 3.2.81-1 x86_64
So they seem fairly similiar? Although I'm not sure how significant the 8 incremements in the least significant digits in the version number is.
On the new server there is no /etc/systemd folder , and on the live server there is a /etc/systemd as explained above. So it does appear to have been installed seperately to the main OS install (as I have a later version of Debian and it wasn't installed on my system by default) - so perhaps there is something related to systemd that is causing the script to start on the live server, but I'm not too sure.
Jessie
In the recent Debian (Jessie) the initv scripts do not work the way they did. And given your kernel version you are not running a Debian that uses initv scripts. The current Debian uses systemd and scripts in /etc/rc.d are run by compatibility features of systemd (the service command is now a systemd command that tries to behave like the old initv command).
You have two options:
Add a line calling the script from /etc/rc.local:
/etc/rc.d/script.sh
This is a rather dirty fix, since it depends on another compatibility feature of systemd. Also, the location of the script does not matter anymore.
Write a full systemd service for uwsgi (this is what I do, and what is recommended by the uwsgi documentation). You would need to create a file called /etc/systemd/system/uwsgi.service with a content similar to:
[Unit]
Description=uwsgi emperor
After=rsyslog.service
[Service]
PIDFile=/run/uwsgi-emperor.pid
ExecStart=/bin/uwsgi --ini /etc/uwsgi/emperor.ini
ExecReload=/bin/uwsgi --reload /run/uwsgi-emperor.pid
ExecStop=/bin/uwsgi --stop /run/uwsgi-emperor.pid
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
I use the emperor mode (which is also the mode recommended by uwsgi for use with systemd), although it is possible to hack it to run a single process uwsgi (see further reading below).
You will also need to enable the service to be used by the multi-user.target, which will run at boot. You need to perform this as root:
systemctl enable uwsgi.service
And uwsgi will start with the next boot (it will not start straight away, to make it start you need systemctl start uwsgi.service).
Further reading:
The Arch linux wiki about systemd is very thorough
The Debian wiki on systemd is good, but outdated in some places (notably, it tells you that you need to install it which is not the case in Jessie)
Weezy
You're mixing things up a little there: chkconfig is a script of the RedHat family of OSes. Making it work for Debian was not easy in the past, and I do not believe it is easy to do so now.
Weezy still uses the initv rc.d folders alright, for each runlevel one rc.d folder:
/etc/rc.d/rc0.d/
/etc/rc.d/rc1.d/
/etc/rc.d/rc2.d/
/etc/rc.d/rc3.d/
/etc/rc.d/rc4.d/
/etc/rc.d/rc5.d/
/etc/rc.d/rc6.d/
You can check the runlevel you are in with the (appropriately named) runlevel command. Then you need to check whether there is a softlink to the script in the correct /etc/rc.d/rc*.d folder. If there is no softlink to the script you need to add it with something of the lines:
ln -s /etc/rc.d/init.d/script.dh /etc/rc.d/rc$(runlevel | cut -d ' ' -f 2).d/script.sh
And that is almost all about how initv scripts work. If you are going into runlevel 2 when the machine boots (I believe that's the default on Debian), what init performs is simply service <script> start for every file in /etc/rc.d/rc2.d.
I want to greet a certain user ffki-besucher in a certain IRC channel.
Whenever that user logs in, it should get a special message written directly into the channel. I heard weechat is a good solution, but how can I achieve this?
How do I install weechat on debian wheezy?
I already installed some packages:
apt-get install weechat-curses weechat-plugins weechat-scripts perl
I use this cool guide at https://weechat.org/files/doc/stable/weechat_quickstart.en.html
Then I start weechat as user (not root):
weechat-curses
(in case you want to quit, use /quit)
Now I need the scripts, but I am stuck how to get this command running:
/script install buffers.pl
I also tried to load the script plugin again with
/plugin autoload script
The script plugin seems to be missing on debian! weechat in debian wheezy is quite old (0.3.8 which has a bug that the script plugin is not included in the debian package)
(I tried to install weechat from jessie, but that would give dependencie problems with some pelrl libs, that go down to the kernel)
Uninstall the repository packages with
apt-get remove weechat*
and install the new packages directly from the weechat download site which are version 1.0.1-1:
cd /tmp/
wget https://weechat.org/debian/dists/stable/main/binary-amd64/weechat-core_1.0.1-1_amd64.deb
wget https://weechat.org/debian/dists/stable/main/binary-amd64/weechat-curses_1.0.1-1_amd64.deb
wget https://weechat.org/debian/dists/stable/main/binary-amd64/weechat-plugins_1.0.1-1_amd64.deb
install guile:
aptget install guile-2.0-libs
then install the packages:
dpkg -i weechat-*
Now you can start weechat as user (not as root) and install the scripts:
/script install buffers.pl
/script install jnotify.pl
Connect to your server:
/server add oftc irc.oftc.net/6667
further set your connection like described here: https://weechat.org/files/doc/stable/weechat_quickstart.en.html#irc_server_options
some tips:
autocomplete with TAB or Shift-TAB
change buffer with Alt+1 or Alt+2,...
install beep.pl to send a notification through screen to your desktop (needs some configuration)
use /help jnotify to achieve the auto notifications to certain users, etc
Install irssi instead:
apt-get install irssi
su into your user and add the trigger.pl script. create:
mkdir -p ~/.irssi/scripts
cd ~/.irssi/scripts
git clone https://github.com/coekie/irssi-scripts/ coeki-irssi-scripts
ln -s coeki-irssi-scripts/trigger.pl
mkdir autorun
cd autorun
ln -s ../trigger.pl
Now start irssi as user
/connect irc.hackint.org
/join #ffki
/nick bot-rubo77
You can later edit your ~/.irssi/config file to autojoin your server and channel with a certain nick:
{ address = "irc.hackint.net"; chatnet = "hackint"; port = "6697"; use_ssl="yes"; autoconnect="yes"; },
...
chatnets = {
hackint = {
type = "IRC";
nick="bot-rubo77";
};
};
change to the status window (ESC 1) and create the trigger:
/trigger add -joins -channels "#ffki" -masks "*ffki-b*#*" -command "msg #ffki Hi $N! Please be patient! Not everyone is at the keyboard but you will be noticed in a few minutes ..."
/trigger save
some tips:
ESC 1 - switch to status window
ESC 2 - switch to window 2 (usually your first chat window) ...
/names shows all users in the channel
you can change the trigger in ~/.irssi/triggers and then type /trigger reload in the status window
When I execute this command below:
scp -P 36000 hdfs#192.168.0.114:~/tmp.txt SOQ_log.txt
I get an error:
command-line: line 0: Bad configuration option: PermitLocalCommand
Does anyone know why?
scp runs a copy of the ssh program to create the communications channel, and it runs ssh with the options:
-oForwardAgent=no -oPermitLocalCommand=no -oClearAllForwardings=yes
So that explains where the "PermitLocalCommand" option is coming from in the first place. I'll add that sftp uses the same options to run ssh, so it'll probably display the same behavior.
"PermitLocalCommand" is normally a valid ssh configuration option. If your copy of ssh is complaining about it, then it seems that your copy of ssh isn't the normal copy of ssh that goes with your copy of scp.
This serverfault question suggests that the error could be due to someone installing a malware version of ssh (ie, a rootkit) on your system. This forum thread also suggests that the problem is due to having an altered version of ssh, which was fixed by removing and reinstalling the OpenSSH client utilities.
An alternate explanation would be that someone--maybe your Linux distro maintainer--has installed a version of ssh on your system with that option removed, and you're using it unawares. Or you have a very old version of the ssh program for some reason, which doesn't support the option.
My system is CentOs 5.9
I'm facing the same problem, I found it to be due to this configuration line in /etc/ssh/sshd_config:
# override default of no subsystems
Subsystem sftp /opt/libexec/sftp-server
But I cannot run /opt/libexec/sftp-server, it is broken for some reason
now it is solved by reinstall the remote openssh-server:
yum erase openssh-server
yum install openssh-server
now the changes to
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
and /usr/libexec/openssh/sftp-server is runnable
don't forget to execute:
/etc/init.d/sshd restart
Sometimes command cannot parse this kind of stuff
:~/
Id change it to the full path.