I would like to chroot my ssh connexion on my debian 8 server but I ahve a problem.
I found this tutorial https://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny but I have an error.
I sue this script:
http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh
he say:
usermod: user johnde is currently used by process 21730
Adding User rdata to jail
Copying necessary library-files to jail (may take some time)
cp: cannot stat '/lib/libnss_compat.so.2': No such file or directory
cp: cannot stat '/lib/libnsl.so.1': No such file or directory
cp: cannot stat '/lib/libnss_files.so.2': No such file or directory
cp: cannot stat '/lib/libcap.so.1': No such file or directory
cp: cannot stat '/lib/libnss_dns.so.2': No such file or directory
Copying files from /etc/pam.d/ to jail
Copying PAM-Modules to jail
cp: cannot stat '/lib/security': No such file or directory
Did i make something wrong ?
thanks.
The library file locations changed between Lenny (actually Squeeze) and Jessie. Compare the path to libnss_compat.so.2 in squeeze to the one in jessie and adapt the code accordingly.
Hard-coding paths in the script seems less than ideal, anyway; perhaps, the part of the code which figures out where to find libraries (the part with ldd) should perhaps remember where it found them, and attempt to copy the remaining libraries from the same location(s).
Here is a patch file to fix make_chroot_jail.sh so it works with Debian 8.2 (aka Jessie) 32-bit. In theory it should work with the amd64 version too as I looked up the new lib folder names for it too. But I have not tested that.
http://www.jonmccain.net/downloads/make_chroot_jail_jessie.patch
use the command:
patch -i make_chroot_jail_jessie.patch -o make_chroot_jail_jessie.sh
to get the new script.
Related
I am quite a beginner in Linux and trying to install gurobi for linux. The installation guide says to move the downloaded file with the following command:
sudo mv ~/Downloads/gurobi9.5.2_linux64.tar.gz /opt/
When I run this, I get the response:
mv: cannot stat '/home/laukna/Downloads/gurobi9.5.2_linux64.tar.gz': No such file or directory
Is there any way to fix this?
The tilde "~" symbol is "a Linux 'shortcut' to denote a user's home directory. Thus tilde slash (~/) is the beginning of a path to a file or directory below the user's home directory." (quoted from twiki.org)
So if your file isn't located in your home directory (which is what your message "No such file..." implies) then you need to write the absolute path to where that file is. If you don't know, you can find it with
find / -name "gurobi9.5.2_linux64.tar.gz"
The issue is that Linux is not recognizing the gurobi file, What is the file name? seems that is not gurobi9.5.2_linux64.tar.gz
You need check the file name in Downloads folder, replace in the command and run again.
sudo mv ~/Downloads/<FILE NAME>.tar.gz /opt/
I know the premise of the question may be confusing, but I want to understand what happened.
Recently I have been experimenting with the rockchip OK3399 single-chip computer(see here) and have installed a linux system on it with TF card installation. Using Putty and connecting with serial protocol, I was able to establish a connection with the OK3399 computer and control it through my laptop.
I am trying to self-learn some linux with the OK3399 system. I created a bash code by the name of displayvids.sh inside the directory /usr/bin, which is meant to take a variable number of pictures with a mipi camera and then save in a directory for work.
I finished writing the code, but for some reason I cannot run the .sh file when my working directory is not the /usr/bin directory, despite /usr/bin being in the %PATH% environment variable. So, I executed the following command:
mv /usr/bin/display* /usr/local/bin
... attempting to move the file to /usr/local/bin instead. The command ran successfully, but when I tried to run the command:
cd /usr/local/bin
It tells me that I cannot cd to bin
As seen from the above image, the /usr/local/bin is not even a directory. Why would mv succeed if the target was not a directory? How can I retrieve my bash file?
Why would mv succeed if the target was not a directory?
mv can also rename files:
mv foo.txt bar.txt
You renamed your script to bin and moved it under /usr/local.
You may want to remember to add a trailing slash next time, to have mv barf if the target isn't a directory:
mv /usr/bin/display* /usr/local/bin/
How can I retrieve my bash file?
Rename it back.
mv bin displayvids.sh
For future reference, you can use the file command to (try to) identify the contents of a file, if it's installed:
file bin
would have probably said bin: Bash script or similar.
I have to mount five of my main directories viz. (/home, /usr, /tmp, /root and /var) for a specific project. I did some googling and found out a set of commands which can be executed to mount a particular directory. The commands were as follows:
#dd if=/dev/zero of=/filesystems/tmp_fs seek=512 count=80000000 bs=1M
#mkfs.ext3 /filesystems/tmp_fs
After mounting, the entry was registered in fstab as below,
/filesystems/tmp_fs /tmp ext3 noexec,nosuid,loop 1 1
And at the last step, the directory was mounted.
I followed the same procedure for mounting all the directories specified above. In the end, I could only mount "/root" and "/tmp" directories without any errors. Rest all the three directories gave some or the other error. After mounting '/home' directory, I am getting the following error "No directory. logging in with HOME=/" and similarly after mounting '/var'
directory I got the following error "/var/lib/apt//lists No such file
or directories". Mounting of '/usr' directory caused the OS to crash as
a result of which we could not even login as root user and also some
basic commands like 'vi' and 'sudo su', to name a few were not found in
the system. ecause of these issues, the only option left was to format
the OS since we could not even revert this step because of the missing
commands.
Any help or suggestion here in the right direction would be of great help here.
Thanks for the consideration.
I am using a script on RHEL server where I'm copying a backup of the /etc/syslog.conf file before making configurable changes in it. I used the below command in the script:
cp -pr /etc/syslog.conf /etc/syslog.conf.bkp.`date +"%d%m%Y"`
The script ran absolutely fine on one RHEL server, but on the other it shows the below error:
cp: cannot stat `/etc/syslog.conf': No such file or directory
I also checked the /etc/syslog/conf file exists in the server just fine.
Why is the difference of behaviour. How to resolve it ?
cp: cannot stat is mainly because cp command can't see the file. It can be for two reasons.
File is not present
You don't have permission to view the file.
If you check these two things you should be able to find the answer
I have a folder /cygwin/d/myfolder/
And everytime I save files there, from cygwin if i do an ls -la I see that the files are given permission 000. That actually causes me quite a bit of problem as I rsync this folder to my server and none of the files are accessible. How can I get the files to automatically get a reasonable permission?
Have a read through the answers at this link:
http://cygwin.1069669.n5.nabble.com/vim-and-file-permissions-on-Windows-7-td61390.html
The solution there worked for me also:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
Then close all Cygwin processes, open a new terminal and ls -l on your files again.
Explanation:
By default, Cygwin uses the filesystem's access control lists (ACLs) to implement real POSIX permissions. Some Windows-native program or process may create or modify the ACLs such that Cygwin computes the POSIX permissions as 000. With the noacl mount option, Cygwin ignores filesystem ACLs and only fakes a subset of permission bits based on the DOS readonly attribute.
Check to make sure that your umask is set correctly with the umask command. If your umask is say 0777 that subtracts from the permissions of new files and will end up with 000 permissions. There's probably several other possibilities to consider beyond that.
If your id is not set up correctly in /etc/passwd and /etc/group that can also cause ls to show unexpected results. Check the permissions of the folder. Also check the Windows permissions with the getfacl command. Maybe also check the mount command.
In above answer, solution was proposed:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
And in that answer there was this comment:
When I try this, all my files are -rw-r--r-- no matter what chmod() I do. I can't mark the files as executable; it just reverts to 0644. (umask==0022)
I had this same problem, but it manifested in inability to execute DOS batch files (*.bat) when running Cygwin ksh or mksh. I stumbled across this website: http://pipeline.lbl.gov/code/3rd_party/licenses.win/cygwin-doc-1.4/html/faq/ which contains this helpful advice:
Note that you can use mount -x to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.
So then cross-referencing with this page - https://cygwin.com/cygwin-ug-net/using.html#mount-table - with its advice:
cygexec - Treat all files below mount point as cygwin executables.
I added cygexec to fourth field of my fstab. This did it. My .bat is now executable inside ksh/mksh, which is necessary since I'm running a Jenkins job that calls a Korn shell stack 3 files deep, that I have no modifiable control over. I just needed the .bat to run!
Update: the solution above wasn't quite what I needed, on further testing. It resulted in some executables such as javac and cl to behave oddly (the utilities would print their usage and exit). I think what I needed instead of 'cygexec' was just 'exec'. As the same page notes:
exec - Treat all files below mount point as executable.
On my Win7 PC files were usually
----------+ 1 David None 69120 Jun 17 13:17 mydoc.txt
I tried all of above no luck
Turned out I still had some old historical mount entries in my .zshrc
I deleted these and Bob's your Uncle problem gone away!