I'd like to automatically set the i.p address of usb port which is configured in cdc mode for my imx6 board.
I have tried manually setting the
I have also written a script to do this after boot.
(after we login as root).
Both of them work but I'd like this to happen before the board asks for login prompt.
This was the content of the script
ifconfig usb0 192.168.100.100
placed in /etc/profile.d
I need to first login as root and then I can see the ip of usb0.
Is it possible to have usb0's i.p set before login?
I would create a meta-custom/recipes-core/systemd-conf/files/06-usb0.network file:
[Match]
Name=usb0
[Network]
Address=192.168.100.100/24
With meta-custom/recipes-core/systemd-conf/systemd-conf_%.bbappend recipe:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://06-usb0.network"
do_install_append() {
install -d ${D}${sysconfdir}/systemd/network
install -m 0644 ${WORKDIR}/06-usb0.network ${D}${sysconfdir}/systemd/network
}
FILES_${PN} += "${sysconfdir}/systemd/network/06-usb0.network"
Note: if you don't use latest Yocto release, it should be systemd-conf.bbappend instead of systemd-conf_%.bbappend
So I found a script
/etc/rc.local
It was mentioned that the script does nothing so I guess that means I can modify it as I wish.
I just added
ifconfig usb0 192.168.100.100
at the start, and the usb i.p seem's to have set before login.
This however seems like a dirty solution, If there is a cleaner way please let me know.
Related
First off: I have read the answers to similar questions on SO, but none of them worked.
IMPORTANT NOTE: The answer below is still valid, but maybe jump to the end for an alternative.
The situation:
App with GUI is running in a docker container (CentOS 7.1) under Arch Linux. (machine A)
Machine A has a monitor connected to it.
I want to access this GUI via X11 forwarding on my Arch Linux client machine. (machine B)
What works:
GUI works locally on machine A (with /tmp/.X11-unix being mounted in the Docker container).
X11 forwarding of any app running outside of docker (X11 forwarding is set up and running properly for non-docker usage).
I can even switch the user while remotely logged in, copy the .Xauthority file to the other user and X11 forwarding works as well.
Some setup info:
Docker networking is 'bridged'.
Container can reach host (firewall is open).
DISPLAY variable is set in container (to host-ip-addr:10.0 because of TCP port 6010 where sshd is listening).
Packets to X forward port (6010) are reaching the host from the container (tcpdump checked).
What does not work:
X11 forwarding of the Docker app
Errors:
X11 connection rejected because of wrong authentication.
xterm: Xt error: Can't open display: host-ip-addr:10.0
Things i tried:
starting client ssh with ssh -Y option on machine B
putting "X11ForwardTrusted yes" in ssh_config on machine B
xhost + (so allow any clients to connect) on machine B
putting Host * in ssh_config on machine B
putting X11UseLocalhost no in sshd_config on machine A (to allow non-localhost clients)
Adding the X auth token in the container with xauth add from the login user on machine A
Just copying over the .Xauthority file from a working user into the container
Making shure .Xauthority file has correct permissions and owner
How can i just disable all the X security stuff and get this working?
Or even better: How can i get it working with security?
Is there at least a way to enable extensive debugging to see where exactly the problem is?
Alternative: The first answer below shows how to effectively resolve this issue. However: I would recommend you to look into a different approach all together, namely VNC. I personally switched to a tigerVNC setup that replaces the X11 forwarding and have not looked back. The performance is just leagues above what X11 forwarding delivered for me. There might be some instances where you cannot use VNC for whatever reason, but i would try it first.
The general setup is now as follows:
-VNC server runs on machine A on the host (not inside a docker container).
-Now you just have to figure out how to get a GUI for inside a docker container (which is a much more trivial undertaking).
-If the docker container was started NOT from the VNC environment, the DISPLAY variable maybe needs ajdusting.
Thanks so much #Lazarus535
I found that for me adding the following to my docker command worked:
--volume="$HOME/.Xauthority:/root/.Xauthority:rw"
I found this trick here
EDIT:
As Lazarus pointed out correctly you also have to set the --net=host option to make this work.
Ok, here is the thing:
1) Log in to remote machine
2) Check which display was set with echo $DISPLAY
3) Run xauth list
4) Copy the line corresponding to your DISPLAY
5) Enter your docker container
6) xauth add <the line you copied>*
7) Set DISPLAY with export DISPLAY=<ip-to-host>:<no-of-display>
*so far so good right?
This was nothing new...however here is the twist:
The line printed by xauth list for the login user looks something like this (in my case):
<hostname-of-machine>/unix:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>
Because i use the bridged docker setup, the X forwarding port is not listening locally, because the sshd is not running in the container. Change the line above to:
<ip-of-host>:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>
In essence: Remove the /unix part.
<ip-of-host> is the IP address where the sshd is running.
Set the DISPLAY variable as above.
So the error was that the DISPLAY name in the environment variable was not the "same" as the entry in the xauth list / .Xauthority file and the client could therefor not authenticate properly.
I switched back to an untrusted X11 forwarding setting.
The X11UseLocalhost no setting in the sshd_config file however is important, because the incomming connection will come from a "different" machine (the docker container).
This works in any scenario.
Install xhost if you don't have it. Then, in bash,
export DISPLAY=:0.0
xhost +local:docker
After this run your docker run command (or whatever docker command you are running) with -e DISPLAY=$DISPLAY
It works usually via https://stackoverflow.com/a/61060528/429476
But if you are running docker with a different user than the one used for ssh -X into the server with; then copying the Xauthority only helped along with volume mapping the file.
Example - I sshed into the server with alex user.Then ran docker after su -root and got this error
X11 connection rejected because of wrong authentication.
After copying the .XAuthoirty file and mapping it like https://stackoverflow.com/a/51209546/429476 made it work
cp /home/alex/.Xauthority .
docker run -it --network=host --env DISPLAY=$DISPLAY --privileged \
--volume="$HOME/.Xauthority:/root/.Xauthority:rw" \
-v /tmp/.X11-unix:/tmp/.X11-unix --rm <dockerimage>
More details on wiring here https://unix.stackexchange.com/a/604284/121634
Some clarifying remarks. Host is A, local machine is B
Ive edited this post to note things that I think should work in theory but haven't been tested, vs things I know to work
Running docker non-interactively
If your docker is running not interactively and running sshd, you can use jumphosts or proxycommand and specify the x11 client to run. You should NOT volume share your Xauthority file with the container, and sharing -e DISPLAY likely has no effect on future ssh sessions
Since you essentially have two sshd servers, either of the following should work out of the box
if you have openssh-client greater than version 7.3, you can use the following command
ssh -X -J user-on-host#hostmachine,user-on-docker#dockercontainer xeyes
If your openssh client is older, the syntax is instead
(google says the -X is not needed in the proxy command, but I am suspicious)
ssh -X -o ProxyCommand="ssh -W %h:%p user-on-host#hostmachine" user-on-docker#dockermachine xeyes
Or ssh -X into host, then ssh -X into docker.
In either of the above cases, you should NOT share .Xauthority with the container
Running docker interactively from within the ssh session
The easiest way to get this done is to set --net=host and X11UseLocalhost yse.
If your docker is running sshd, you can open a second ssh -X session on your local machine and use the jumphost method as above.
If you start it in the ssh session, you can either -e DISPLAY=$DISPLAY or export it when you're in. You might have to export it if you attach to an exiting container where this line wasn't used.
Use these docker args for --net host and x11uselocalhost yes
ssh -X to host
-e DISPLAY=$DISPLAY
-v $HOME/.Xauthority:/home/same-as-dash-u-user/.Xauthority
-u user
What follows is explanation of how everything works and other approaches to try
About Xauthority
ssh -X/-Y set up a session key in the hosts Xauthority file, and then sets up a listen port on which it places an x11 proxy that uses the session key, and converts it to be compatible with the key on your local machine. By design, the .Xauthority keys will be different between your local machine and the host machine. If you use jumphosts/proxycommand the keys between the host and the container will yet again be different from each other. If you instead use ssh tunnels or direct X11 connection, you will have to share the host Xauthority with the container, in the case of sharing .Xauthority with the container, you can only have one active session per user, since new sessions will invalidate the previous ones by modifying the hosts .Xauthority such that it only works with that session's ssh x11 proxy
X11UserLocalhost no theory##
Even Though X11UseLocalhost no causes the x server to listen on the wildcard address, With --net host I could not redirect the container display to localhost:X.Y where x and why are from the host $DISPLAY
X11UseLocalhost yes is the easy way
If you choose X11UseLocalhost yes the DISPLAY variable on the host becomes localhost:X:Y, which causes the ssh x11 proxy to listen only on localhost port x.
If X11UseLocalhost is no, the DISPLAY variable on the host becomes the host's hostname:X:Y, which causes the xerver to listen on 0.0.0.0:6000+X and causes xclients to reach out over the network to the hostname specified.
this is theoretical, I don't yet have access to docker on a remote host to test this
But this is the easy way. We bypass that by redirecting the DISPLAY variable to always be localhost, and do docker port mapping to move the data from localhost:X+1.Y on the container, to localhost:X.Y on the host, where ssh is waiting to forward x traffic back to the local machine. The +1 makes us agnostic to running either --net=host or --net=bridge
setting up container ports requires specifying expose in the dockerfile and publishing the ports with the -p command.
Setting everything up manually without ssh -X
This works only with --net host. This approach works without xauth because we are directly piping to your unix domain socket on the local machine
ssh to host without -X
ssh -R6010:localhost:6010 user#host
start docker with -e DISPLAY=localhost:10.1 or export inside
in another terminal on local machine
socat -d -d TCP-LISTEN:6010,fork UNIX-CONNECT:/tmp/.X11-unix/X0
In original terminal run xclients
if container is net --bridged and you can't use docker ports, enable sshd on the container and use the jumphosts method
I currently have my Raspberry pi setup with network connectivity and i can connect to it via local ip addres like this:
192.168.0.x
Is there anyway i use my puplic ip to ssh into my raspberry pi ?
I think a Dynamic DNS is usualy the way to go. I use FreeDNS and I think it's pretty good. Instructions for setup by dentaku65:
First of all register your account on Freedns. Freedns offers a bunch of domain names, from my taste the best ones (or the ones easy to remember) are:
mooo.com
ignorelist.com
Assume that you register: your_host>.ignorelist.com
Install inadyn:
sudo apt-get install inadyn curl
Open the url: http://freedns.afraid.org/dynamic/
Login with your account
Select the link Direct URL beside .ignorelist.com
Copy everything from the right of the ? in the address bar (alphanumeric string)
Create configuration file of inadyn:
sudo gedit /etc/inadyn.conf
And save this content:
--username <your_username>
--password <your_password>
--update_period 60000
--forced_update_period 320000
--alias <your_host>.ignorelist.com,alphanumeric string
--background
--dyndns_system default#freedns.afraid.org
--syslog
Add inadyn to crontab:
export EDITOR=gedit && sudo crontab -e
Edit the file to add the following line:
#reboot /usr/sbin/inadyn
Reboot your PC
Wait 3 minutes
Check if inadyn is running:
ps -A | grep inadyn
Check inadyn behaviour:
more /var/log/messages |grep INADYN
Check if your host is up:
ping <your_host>.ignorelist.com
There are two possible solutions to this problem.
If your ISP provides public ip, you can use dynamic DNS services from no-ip or dyndns or any other equivalent service providers and you can forward port #22 to rpi ip using your router menu.
If your ISP doesn't provide public ip and you are behind NAT. You can make use of reverse remote ssh method mentioned in this link. But to access via this method, you need a server in between that's having a public ip. http://www.tunnelsup.com/raspberry-pi-phoning-home-using-a-reverse-remote-ssh-tunnel
Hope it helps.
you may need to enable portfowarding on your router
Is anyone can give to me the FULL process to set up X11 forwarding from a CentOS fresh and clean install on a dedicated server ?
So, i have access to the server only by ssh
The problem is simple : i already tried i think all solution i find in google to make X11 forwarding working :
set in /etc/ssh/sshd_config
X11Forwarding yes
and
X11UseLocalhost no or X11UseLocalhost yes
and
XAuthLocation /usr/bin/xauth (and xauth is in this path)
and
AddressFamily inet or AddressFamily any
restarting sshd after each write with /etc/init.d/sshd restart (and it tell to me it stop and start)
i tried to install many and many things (restarting sshd after each install) like :
yum groupinstall 'X Window System' (it works well)
xorg-x11-utils (it works)
xorg-x11-fonts-* (it works)
xorg-x11-xauth (already installed)
yum install xorg-x11-xauth.x86_64 (it works)
when i try "strings /usr/sbin/sshd |grep xauth" i got :
/usr/bin/xauth
xauthlocation
maxauthtries
No xauth program; cannot forward with spoofing.
but /usr/bin/xauth give me :
Using authority file /root/.Xauthority
xauth>
so xauth is in the right place...
i tried all ssh option -X, -x, -Y -XY.... nothing worked.
i tried to set display myself, but nothing worked :
DISPLAY is not set, Can't open display and other errors like that.
And just after ssh login $DISPLAY is empty, always.
And i'm not sure that i have not forget some solution i have already tried...
Anyone to help me to get X11 forwarding working ?
I have
CentOS release 6.5 (Final)
and my hoster is OVH
PS : sorry for my bad english
I encountered this same issue, due to an ~/.Xauthority file not being generated for new users upon connecting via ssh. I'd made all appropriate changes to /etc/ssh/sshd_config and /etc/ssh/ssh_config and reset the service via
/etc/init.d/sshd restart
But I never had any luck until I changed my SELinux settings after finding this - ssh X11 forwarding won't work
Of course, you only want to implement changes to SELinux if it's acceptable for your use case. But for me, setting SELinux to permissive with
setenforce 0
and setting the following in /etc/selinux/config - so that this change persisted after reboot
SELINUX=permissive
I would like to emphasize that my situation is a non-critical operation within a (hopefully!) securely-managed intranet. I would NOT suggest turning off SELinux at work, or at home if you're hoping to open ports or configure VPN for your home network. Please consider: http://securityblog.org/2006/05/21/software-not-working-disable-selinux/
I have a headless Ubuntu server. I ran a command on the server (snapraid sync) over SSH from my Mac. The command said it would take about 6 hrs, so I left it over night.
When I came down this morning, the Terminal on the Mac said: "Write failed: broken pipe"
I'm not sure if the command executed fully. Is this a timeout issue? If so, how can I keep the SSH connection alive overnight?
This should resolve the problem for Mac osX version: 10.8.2
add:
ServerAliveInterval 120
TCPKeepAlive no
to this file:
~/.ssh/config
Or, if you want it to be a global change in the SSH client, to this file
/private/etc/ssh_config
"ServerAliveInterval 120" basically says to "ping" the server with a NULL packet every 120s, and "TCPKeepAlive no" means to not set the SO_KEEPALIVE socket option (since you shouldn't need it with ServerAliveInterval already set, and apparently it's "spoofable" or some odd).
The servers similarly have something they could set for the same effect (ClientKeepAliveInterval) but typically you don't have control over those settings as much.
You can use "screen" util for that. Just connect to the server over SSH, start screen session by "screen" command execution, start your command there and disconnect (don't exit screen session). When you think your command already done you can connect to the server and attach to your screen session where you can see the command execution result/progress (in case one should be).
See "man screen" for more details.
This should resolve the problem for ubuntu and linux mint
add:
ServerAliveInterval 120
TCPKeepAlive yes
to
/etc/ssh/ssh_config file
Instead of screen I'd recommend tmux, an (arguably) better competitor to screen
tmux new-session -s {name}
That command creates a session. Any time after that you want to connect:
tmux a -t {name}
there are two solutions
To update server and restart server sshd
echo "ClientAliveInterval 60" | sudo tee -a /etc/ssh/sshd_config
To update client
echo "ServerAliveInterval 60" >> ~/.ssh/config
After having tried to change many of above parameters in sshd_config (ClientAliveInterval, ClientMaxCount,TCPKeepAlive...) nothing had changed. I have spend hours and days to look for a solution on forums and blogs...
It appears that the problem of broken pipe which forbids to connect with ssh/sftp came from permissions settings on ChrootDirectory.
the ChrootDirectory has to be owned by root/root with 755 permision
lower permissions 765/766/775... won't work but strongers do (eg 700)
if you need to give a write permission to connected user, you can give it in sub-directories.
if chroot is owned by sftpUser:sftpGroup, it won't work neither...
chroot-> root:root 755
|
---subdirectories-> sftpUser:sftpGroup 700 up to 770
hope it would help
If you're still having problem after editing /etc/ssh/sshd_config or if ~/.ssh/config
simply does not exist on your machine then I highly recommend reinstalling ssh. This solution took about a minute to fig both "Broken pipe" errors and "closed by remote host" errors.
sudo apt-get purge openssh-server
sudo apt update
sudo apt install openssh-server
jeremyforan's answer is correct, however I've found that if you are trying to use scp it is necessary to explicitly point it to a config file configured as described, it seems to not obey the normal hierarchy of config. For example:
scp -F ~/.ssh/config myfile joe#myserver.com:~
works, while omitting the -F still results in the broken pipe error.
Ubuntu :
ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=1 user#x.x.x.x
I use an ASUS router with two internet input lines. I appoint my IP to a certain line, and it works.
How can I run a command from a (bash) CGI script to play a wav sound on the server side?
You can execute your command line audio player as described by nak, but this may not work due to the permissions of the user running Apache. By default Apache is run as www-data:www-data (or apache:apache or www:www on some distros). As a quick fix/test you can set Apache to run as a user that has permissions to access the audio device on the machine by modifying your /etc/apache2/apache2.conf (or /etc/httpd/httpd.conf") file to have:
User USER_THAT_CAN_PLAY_AUDIO
Group USER_THAT_CAN_PLAY_AUDIO
Warning: this is not secure and is not intended to be a permanent solution!
This is how I would do it
#!/bin/sh
echo Content-type: text/plain
echo ""
echo "Server is playing sine.wav!"
aplay -q sine.wav
I stumbled over this old question looking how to solve the same problem: to have my personal Apache webserver warning me when someone makes a specific request (in my case a call for chat without the need to have any IM running).
The solution below is what I use on Slackware 14.1: according to your distro YMMV.
launch visudo
add the line TheUserRunningApache ALL=(ALL) NOPASSWD: /usr/bin/play (TheUserRunningApache is the user name used by your Apache)
In the PHP page you want to play a sound add this line: system ("sudo /usr/bin/play SOUND.WAV");
If you don't want to give access to Apache to the /usr/bin folder, even if limited just to play, you can copy the sox executable (the program used to run /usr/bin/play) elsewhere, but you'll have to modify the last two instructions above accordingly.