I have a question, I created a script but I need to create a path, to find my cassandra folder to execute cqlsh, this is the route
C:/apache-cassandra-3.11.4/bin/cqlsh
the problem is because I am in windows not in linux, and I want to see if possible to create an a path in case that I need to pass my script to my team. but you know your cassandra db is in another route for that reason I want to do that because I need to execute this script
example
route= /../cassandra3.11.4/bin/cqlsh
$route -k fsainstqual -e "TRUNCATE instrumentmanufacturer"
If you mean you don't know how to mix Windows drive letters and Linux directory handling (which does not have drives), you'll need mounting points, as you can see in following mount excerpt on my PC, where I have a Linux app installed:
Prompt>mount
...
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)
E: on /mnt/e type drvfs (rw,noatime,uid=1000,gid=1000,case=off)
In top of that, on my root directory, I've created symlinks to those mounted directories:
Prompt>cd /
Prompt>$ ls -ltra | grep "\->"
lrwxrwxrwx 2 root root 6 Nov 23 2017 C -> /mnt/c
lrwxrwxrwx 2 root root 6 Nov 14 12:00 E -> /mnt/e
I think it's better to clarify your question buddy.
If you want to change your current directory, you can use "cd" command as in linux shell.
If you want to create a path use "md" or "mkdir" command.
Here is the help in windows OS
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/md
Related
I'm using QEMU to test Raspberry Pi before putting the image onto an SD card. I'm setting up an automated script to put some files onto the Pi, among other things, so that when I put the SD card into the Pi, it is immediately usable. I think I've run into a quirk in how permissions work, but I'm not sure.
When you run test -x, the file is supposed to be executable. Basically, the x bit is supposed to be on for your user. However, this doesn't seem to apply to files inside mounted filesystems.
The host is Ubuntu, and the guest backing image is Raspberry Pi Buster. I created the mountpoint with guestmount, because I was mounting a snapshot, not the original, and this seems to be the only/best way to do that. The basic flow was:
qemu-img convert -Oqcow2 raspberry-pi.img raspberry-pi.qcow
qemu-img create -f qcow2 snapshot.qcow -b raspberry-pi.qcow
sudo guestmount -a 'snapshot.qcow' -i 'mountpoint/'
For example, I have a file outside the repository. The file I'm testing inside the mountpoint was created by root, so I chmoded this file to root for comparison:
$ sudo ls -l --author ~/test/file
-rw-r--r-- 1 root root root 1133 Oct 8 21:43 /home/me/test/file
$ sudo test -x ~/test/file && echo 'exists' || echo 'doesn\'t exist'
doesn't exist
However, for a file inside the mountpoint, with the same permissions, the test is successful:
$ sudo ls -l --author mountpoint/home/pi/test/file
-rw-r--r-- 1 root root root 0 Oct 8 22:41 mountpoint/home/pi/test/file
$ sudo test -x ~/test/file && echo 'exists' || echo 'doesn\'t exist'
exists
Why is the file inside the mountpoint executable, whereas the one outside is not executable? Is this because the mounted filesystem is a different architecture (x86 vs. ARM)? Is it because I'm using guestmount, and the filesystem isn't the real filesysem, but an amalgamation of the snapshot & the original file? Or is this just the way mounting works? Where can I find more resources on this peculiar behavior, like other permission quirks I might encounter?
If you need any more information about the host or guest, please ask.
This is a bug in libguestfs used by guestmount. You can see it here:
/* Root user should be able to access everything, so only bother
* with these fine-grained tests for non-root. (RHBZ#1106548).
*/
if (fuse->uid != 0) {
[...]
if (mask & X_OK)
ok = ok &&
( fuse->uid == statbuf.st_uid ? statbuf.st_mode & S_IXUSR
: fuse->gid == statbuf.st_gid ? statbuf.st_mode & S_IXGRP
: statbuf.st_mode & S_IXOTH);
}
The FS takes a shortcut saying that since you're root you have full access, so there's no point checking the permissions.
As you've demonstrated, this is not true. Root should only have execute permissions for directories, and for files where at least one of the execute bits is set.
I was unable to build the project to submit a patch, but you can file a bug.
For the RTOS I'm writing ( http://www.distortos.org ) I need to run find as part of the build configuration process (from make menuconfig target). For Windows I assume that user has MSYS2 installed, so find.exe is available. The only problem with this particular file is that Windows also has such file in C:/Windows/system32 (supposedly it is something close to grep). So depending on the order of folders in your PATH environment variable you get one or the other if trying to call the file by just the name.
I've found that calling this program as /bin/find from the Makefile or in shell script works both in Windows and on (my) Linux. What is most important - doing it that way always calls find.exe from MSYS2, no matter what is the order of folders in PATH. So I'm wondering - is it OK to call find this way, or maybe it is not portable and I just had luck that it works for me?
It would probably be more portable to refer to it as /usr/bin/find. For example, on Fedora /bin is actually a symlink to /usr/bin, so either works:
bash-4.3$ ls -l /bin/find
-rwxr-xr-x. 1 root root 222608 Dec 28 18:26 /bin/find
bash-4.3$ ls -l /usr/bin/find
-rwxr-xr-x. 1 root root 222608 Dec 28 18:26 /usr/bin/find
But on a recent Ubuntu:
root#69ca68fbe5c0:/# ls -l /bin/find
ls: cannot access /bin/find: No such file or directory
root#69ca68fbe5c0:/# ls -l /usr/bin/find
-rwxr-xr-x. 1 root root 229992 Jan 6 2014 /usr/bin/find
I would recommend not hard-coding the path to find and instead instruct Windows users that they must run your script inside the MSYS2 environment. MSYS2 will put its own bin directories near the beginning of the path so that find always gets the MSYS2 version instead of the Microsoft version.
If you hard-code the path to find then you make things be more brittle than they need to be.
I have some mod_perl code trying to access a file under /tmp ... but it throws a 'no such file or directory' error. I added an 'ls -al /tmp' to my code to see what Perl was seeing inside the directory, and it only gave me . and .. :
drwxrwxrwt. 2 root root 6 Jan 21 13:36 .
drwxrwxrwx. 18 root sysadmin 4096 Nov 22 22:14 ..
In reality there are a mixture of files under /tmp, including some owned by the Apache user. Changing my code to 'ls -al /' gives a correct directory listing (nothing missing).
I tried sudo'ing to the Apache user, and can see under /tmp file, so it must be something mod_perl related.
Ideas? I'm running mod_perl 2.0.8 and Apache 2.4 under CentOS 7. SELinux is set to permissive.
So based on comments the answer here is - it's an RHEL 7 feature.
https://securityblog.redhat.com/2014/04/09/new-red-hat-enterprise-linux-7-security-feature-privatetmp/
PrivateTmp=
Takes a boolean argument. If true sets up a new file system
namespace for the executed processes and mounts a private /tmp
directory inside it, that is not shared by processes outside of
the namespace. This is useful to secure access to temporary files
of the process, but makes sharing between processes via /tmp
impossible. Defaults to false.
I use both winsymlinks:native and cygwin symlinks depending on if windows needs to and CAN follow the link. I'd like to have a cygwin way to see what kind of symlink it is since it just sees a symlink but DOS sees the difference. I need to know the diff so I can handle rsyncing/etc/ and have the type of symlink preserved (or recreated).
I have the perms to create the dos native ones and have functions to set either:
$ touch test
# cygwin style symlink
$ CYGWIN= ln -s test t1
# WINDOWS style
$ CYGWIN=winsymlinks:native ln -s test t2
# for good measure make one the DOS way
$ cmd /c mklink t3 test
symbolic link created for t3 <<===>> test
cygwin sees them all as symlinks:
$ ls -l
total 1
lrwxrwxrwx 1 user Users 4 Jun 14 11:06 t1 -> test
lrwxrwxrwx 1 user Users 4 Jun 14 11:06 t2 -> test
lrwxrwxrwx 1 user Users 4 Jun 14 11:06 t3 -> test
-rw-rw-rw-+ 1 user Users 0 Jun 14 11:05 test
Windows knows the native symlinks:
Or as seen from DOS:
$ cmd /c dir /a
Volume in drive C is Windows
Directory of C:\Cygwin-32\tmp
06/14/2014 11:06 AM 22 t1
06/14/2014 11:06 AM <SYMLINK> t2 [test]
06/14/2014 11:06 AM <SYMLINK> t3 [test]
06/14/2014 11:05 AM 0 test
4 File(s) 22 bytes
So how do I tell what kind of symlink it is when viewed in CYGWIN? When I rsync these symlinks, cygwin will make all of them at the destination the kind set in the CYGWIN env var. I would like to keep the symlink type in the rsync'd destination or at the very least go through the source folder, figure out the type and change them at the destination. stat also only reports them as symlinks, does not see the difference.
Adding this section because I HATE the "Why do you need (or want) to do that?" answers:
Why do I mix symlinks? I tried setting my overall CYGWIN env var to CYGWIN=winsymlinks:native and CYGWIN=winsymlinks:nativestrict but during some package installs (mostly using apt-cyg) I have had errors in the extracted TAR of a few packages so I left that out and only call CYGWIN=winsymlinks:native as I need them (if windows needs to follow the link). I think the packages are installed as cygwin symlinks from the initial CYGWIN setup.exe so setting that value globally will create the problem later. I've also had the CYGWIN=winsymlinks:nativestrict setting create an actual "/usr/bin/" folder (can see in explorer) but cygwin has /bin mounted as /usr/bin so you get packages extracted that are not found in cygwin.
And also just because there are some symlinks I DON'T want Windows to know about or follow.
I ended up scripting this. The test in cygwin would be to call a dos command and grep for the info needed.
if fsutil reparsepoint query "$1" | grep -iq "Tag value: Symbolic Link" ; then
echo "Windows Native Symlink"
fi
Please let me explain what I mean by the question:
This is the context: I'm a user on a webserver, where I have phpicalendar installed; then, I choose a directory, say /webroot/mylogin/phpicalendar/mycals to host my .ics calendar text files.
EDIT: Previously, instead of '/webroot', I had used '/root' - but I really didn't mean the Linux '/root' directory - I'm just wanted to use it as a stand in for the real location on the webserver (so it serves just as a common point of reference). Otherwise, what I mean by common point of reference, is simply /webroot = /media/some/path ..
Then, I can enter this directory in the phpicalendar's config.inc.php:
$configs = array(
'calendar_path' => '/webroot/mylogin/phpicalendar/mycals;
...
Then, phpicalendar will run through this directory, grab the .ics files there (say, mycal.ics and mycal2.ics) and render them - so far, so good.
The thing is, I would now like to add a second calendar directory, located at the same webserver, but where I have read-only permissions, say /webroot/protected/cals. I know that I have read permissions, because I can do in the shell, say
$ less /webroot/protected/cals/maincal.ics
and I can read the contents fine.. So now:
If I enter /webroot/protected/cals as a 'calendar_path', phpicalendar can read and render the files there (say, 'maincal.ics', 'maincal2.ics') without a problem
However, phpicalendar can have only one 'calendar_path', so I can either use the protected calendars, or my customized calendars - but not both
So, I thought, I could symlink the protected calendars in my customized directory - and get the best of both worlds :)
So, here is a shell snippet of what I would do
$ cd /webroot/mylogin/phpicalendar/mycals
$ ls -la
drwxrwxrwx 2 myself myself 4096 2011-03-03 12:50 .
-rw-r--r-- 1 myself myself 1234 2011-01-20 07:32 mycal.ics
-rw-r--r-- 1 myself myself 1234 2011-01-20 07:32 mycal2.ics
...
$ ln /webroot/protected/cals/maincal.ics . # try a hard link first
ln: creating hard link `./maincal.ics' => `/webroot/protected/cals/maincal.ics': Invalid cross-device link'
$ ln -s /webroot/protected/cals/maincal.ics . # symlink - works
$ ln -s ../../../protected/cals/maincal.ics relmaincal.ics # symlink via relative
$ ln -s mycal.ics testcal.ics # try a symlink to a local file
$ ls -la # check contents of dir now
drwxrwxrwx 2 myself myself 4096 .
-rw-r--r-- 1 myself myself 1234 mycal.ics
-rw-r--r-- 1 myself myself 1234 mycal2.ics
lrwxrwxrwx 1 myself myself 21 testcal.ics -> mycal.ics
lrwxrwxrwx 1 myself myself 56 maincal.ics -> /webroot/protected/cals/maincal.ics
lrwxrwxrwx 1 myself myself 66 relmaincal.ics -> ../../../protected/cals/maincal.ics
Ok, so here's what happens:
less maincal.ics works on shell
less relmaincal.ics fails with 'relmaincal.ics: No such file or directory' (even if shell autocompletion for the relative path did work during the execution of the symlink command!)
When you open phpicalendar now, it will render mycal.ics, mycal2.ics and testcal.ics (and they will work)
however, maincal.ics and relmaincal.ics will not be parsed or displayed
Now - this could be that PHP cannot resolve symlinks; however I speculate that the situation is this:
When I do less maincal.ics - it is myself who is user, who has read permission for /webroot/protected/cals
phpicalendar (so Apache webserver user) can otherwise also access /webroot/protected/cals as read-only, when given 'hardcoded' path
phpicalendar is also capable of reading local symlinks fine
Thus, I suspect, that the problem is: when trying to read the symlinks to protected cals, the user that is visible to the shell during that operation is Apache web user, which then doesn't get permissions to access a symlink to the protected/cals location!
The thing now is - I can easily copy the .ics files locally; however they are being changed by someone else, which is why I'd have preferred a symlink.
And my question is: can I do some sort of trickery, so that when phpicalendar/Apache tries to access a symlink to protected/cals, it 'thinks' that it is a local file - and otherwise, the contents of the protected/cals file are being 'piped' back to phpicalendar/Apache?? I guess I'm thinking something in terms of:
$ mkfifo mypipe
$ ln -s mypipe testpipe.ics
$ cat ./testpipe.ics # in one terminal
$ cat /webroot/protected/cals/maincal.ics > mypipe # in other terminal
... which would otherwise (I think) handle the permissions problem - except that, I don't want to cat manually; that would be something that would have to be done in the background, each time an application requests to read testpipe.ics:)
Well, thanks in advance for any comments on this - looking forward to hearing some,
Cheers!
Umm, I really doubt that the account the web server runs under can read anything under /root. That directory is usually mode 0700, user root, group root, or something very similar to that - meaning no non-root access is allowed. If you're running the web server as root, file read permissions are the least of your problems...
Your best bet then would be to place the read-only calendar files somewhere publicly available, and symlink to that location from wherever under /root you want to be able to access them.
Start by checking whether the Apache user can view your calendars:
you#host $ sudo -i -u <apache-user> -s /bin/bash
apache#host $ less /root/protected/cals/maincal.ics