While extracting a file using this command tar -zxf bluez-arm-package.tgz the owner(1000):group(pulse) of the files and directories is
changing as below example.
Example:
drwxrwxr-x 4 1000 pulse 1024 Jul 21 00:32 dbus-1
The actual should be:
drwxrwxr-x 4 root root 1024 Jul 21 00:32 dbus-1
There is an option for output stream in tar : --no-same-owner
So
tar xvf test_tar.tar --no-same-owner
will probably create files with user who launch this command as owner.
It's a little bit strange as this option (--no-same-owner) should be default for ordinary (non-superuser) users.
Does it work for you?
Related
(ubuntu 18.04)
I'm attempting to extract an odbc driver from a tarball and following these instructions with command:
tar --directory=/opt -zxvf /SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gz
This results in the following output:
root#08ba33ec2cfb:/# tar --directory=/opt -zxvf SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gzSimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/GoogleBigQueryODBC.did
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/release-notes.txt
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/Simba Google BigQuery ODBC Connector Install and Configuration Guide.pdf
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/OEM ODBC Driver Installation Instructions.pdf
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/simba.googlebigqueryodbc.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/odbc.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/odbcinst.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/SimbaODBCDriverforGoogleBigQuery32_2.4.6.1015.tar.gz
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015.tar.gz
The guide linked to above says:
The Simba Google BigQuery ODBC Connector files are installed in the
/opt/simba/googlebigqueryodbc directory
Not for me, but I do see:
ls -l /opt/
total 8
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux
And:
ls -l /opt/SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/
total 52324
-rwxr-xr-x 1 1000 1001 400 Apr 26 00:39 GoogleBigQueryODBC.did
-rw-rw-rw- 1 1000 1001 26688770 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery32_2.4.6.1015.tar.gz
-rw-rw-rw- 1 1000 1001 26876705 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015.tar.gz
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 docs
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 setup
I was specifically looking for the .so driver file. All the above is on a docker container. I tried extracting the tarball locally on Ubuntu 18.04 (Same as my Docker container) and when I use Ubuntu desktop gui to extract by double clicking the tar.gz file and then clicking 'extract', I do indeed see the expected files.
It seems my tar command (tar --directory=/opt -zxvf /SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gz) is not extracting the tarball as expected.
How can I extract the contents of the tarball properly? The tarball in question is the linux one on this link.
[edit]
Adding screens of contents of the tarball per comments. I had to click down two levels of nesting to arrive at 'stuff':
The instructions you linked to do not match the contents of the file I found from here. The first .tar.gz contains two other .tar.gz files. I looked into the 64 bit one and it has:
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/SimbaBigQueryODBCMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/ODBCMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/SQLEngineMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/DSMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/DSCURLHTTPClientMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/third-party-licenses.txt
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/libgooglebigqueryodbc_sb64.so
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/cacerts.pem
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/EULA.txt
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/Tools/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/Tools/get_refresh_token.sh
Your .so is in the lib directory. Based on the instructions it looks like you need to extract this file (or the 32 bit if appropriate) and rename, in this case SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015 to simba/googlebigqueryodbc. The tar command is doing what it is told but the instructions are way off.
I'm new to cmake, and I'm only using it to install opencv on my ubuntu linux.
Here's the command I ran: cmake -DCMAKE_BUILD_TYPE=Release DCMAKE_INSTALL_PREFIX=/home/jinha/OCV/source
Then it returns the error:
FATAL: In-source builds are not allowed. You should create separate directory for build files.
My current directory, ~/OCV/build/opencv, does contain the CMakefiles.txt file, so that's not the problem. I tried to change the directory in my command, but they all raise the same error. I saw the other answers on this issue, so I erased CMakeFiles directory and CMakeCache.txt file every time before I ran the command, but none of them worked.
Thanks.
It wants you to create a separate build directory (anywhere), and run cmake there. For example:
mkdir my_build_dir
cd my_build_dir
rm ../CMakeCache.txt
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/jinha/OCV/source
Note the .. in this example telling cmake where to look for the source.
In case you didn't remove CMakeCache.txt before building again, it will still show this error.
So, please remember to delete CMakeCache.txt first before running cmake.
After you have success downloaded and unzipped OpenCV sources from sources you need create simple command-file install.sh. For example, your working dir will be /home/user/myopencv
So /home/user/myopencv/install.sh will be contain next code:
#!/bin/bash
rm CMakeCache.txt
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/usr/local
make
make install
make clean
Next
chmod 777 install.sh
./install.sh
And after the all you will get those executable files:
root#cartman:/usr/local/bin# ls -las | grep opencv
32 -rwxr-xr-x 1 root root 29888 апр 20 18:10 opencv_annotation
244 -rwxr-xr-x 1 root root 247608 апр 20 18:10 opencv_createsamples
244 -rwxr-xr-x 1 root root 247504 апр 20 18:10 opencv_haartraining
20 -rwxr-xr-x 1 root root 18600 апр 20 18:10 opencv_performance
288 -rwxr-xr-x 1 root root 294592 апр 20 18:10 opencv_traincascade
16 -rwxr-xr-x 1 root root 14288 апр 20 18:10 opencv_version
60 -rwxr-xr-x 1 root root 61040 апр 20 18:10 opencv_visualisation
Enjoy!
I need to tar this dir - totar:
$ ls -l totar/
total 61388
292 -rw-r--r-- 1 wasext was 298867 Apr 13 16:44 application.2015-01-19.0.log
108 -rw-r--r-- 1 wasext was 109623 Apr 14 13:32 application.2015-01-20.0.log
788 -rw-r--r-- 1 wasext was 805468 Apr 14 13:32 application.2015-01-21.0.log
1080 -rw-r--r-- 1 wasext was 1104861 Apr 14 13:32 application.2015-01-22.0.log
2052 -rw-r--r-- 1 wasext was 2098782 Apr 14 13:32 application.2015-01-23.0.log
4 -rw-r--r-- 1 wasext was 455 Apr 14 13:32 application.2015-01-24.0.log
21076 -rw-r--r-- 1 wasext was 21581073 Apr 14 13:32 application.2015-01-26.0.log
9296 -rw-r--r-- 1 wasext was 9519026 Apr 14 13:32 application.2015-01-27.0.log
17912 -rw-r--r-- 1 wasext was 18341302 Apr 14 13:32 application.2015-01-28.0.log
8780 -rw-r--r-- 1 wasext was 8989019 Apr 14 13:32 application.2015-01-29.0.log
I created tarball file with parameter "-C":
$ tar cvf t.tar -C totar/*
tar: can't change directories to totar/application.2015-01-19.0.log: Not a directory
a totar/application.2015-01-20.0.log 215 blocks
a totar/application.2015-01-21.0.log 1574 blocks
a totar/application.2015-01-22.0.log 2158 blocks
a totar/application.2015-01-23.0.log 4100 blocks
a totar/application.2015-01-24.0.log 1 blocks
a totar/application.2015-01-26.0.log 42151 blocks
a totar/application.2015-01-27.0.log 18592 blocks
a totar/application.2015-01-28.0.log 35823 blocks
a totar/application.2015-01-29.0.log 17557 blocks
I got this error:
tar: can't change directories to totar/application.2015-01-19.0.log: Not a directory
In created tar file is missing file: totar/application.2015-01-19.0.log:
$ tar tf t.tar
totar/application.2015-01-20.0.log
totar/application.2015-01-21.0.log
totar/application.2015-01-22.0.log
totar/application.2015-01-23.0.log
totar/application.2015-01-24.0.log
totar/application.2015-01-26.0.log
totar/application.2015-01-27.0.log
totar/application.2015-01-28.0.log
totar/application.2015-01-29.0.log
Can you help me where I made mistake?
With the -C option to tar, you are telling tar to change to that directory first before adding files to the archive. This is very convenient to prevent having to change to that directory to begin with. Say you are in your $HOME directory and want to archive the files in /path/to/totar, then you simply give the -C option to the directory above totar and target directory. If you want to archive /path/to/totar, then you want to:
tar -C /path/to cvf somearchive.tar totar
Note the files spec above totar is a directory name not a filename and will include all files in the totar directory. You do not include wildcards, but you can include specific filenames. To backup only some files in /path/to/totar:
tar -C /path/to/totar cvf somearchive.tar filename
to only filename in the totar directory. (wildcards are not allowed)
I'll see if I can make it clearer: When you enter anything with *, your shell immediately expands it to a list of files that match the patten.
So say you have a simpler directory: totar contains just 3 files: foo, bar, and foobar
When you then type:
tar cvf t.tar -C totar/*
It gets expanded to
tar cvf t.tar -C totar/foo totar/bar totar/foobar
Since -C takes a parameter, tar interprets the next argument, totar/foo, as the parameter of -C. And only totar/bar and totar/foobar remain as the files to be archived.
Do you really need the -C? Because I suggest leaving the -C out completely
$ tar cvf t.tar totar/*
Update:
If you want to retain the behaviour of -C, I strongly suggest that you have a look at #charles-duffy 's comments below.
Cheers
What can I do to make this script run daily?
If I manually run the script, it works. I can see that it did what it's supposed to do. (backup files) However, it will not run as a cron.daily script. I've let it go for days without touching it -- and it never runs.
The actual script is here /var/www/myapp/backup.sh
There is a symlink to it here /etc/cron.daily/myapp_backup.sh -> /var/www/myapp/backup.sh
The cron log at /var/log/cron shows anacron running this script:
Aug 19 03:09:01 ip-123-456-78-90 anacron[31537]: Job `cron.daily' started
Aug 19 03:09:01 ip-123-456-78-90 run-parts(/etc/cron.daily)[31545]: starting myapp_backup.sh
Aug 19 03:09:01 ip-123-456-78-90 run-parts(/etc/cron.daily)[31559]: finished myapp_backup.sh
Yet there is no evidence that the script actually did anything.
Here is the security info on these files:
ls -la /var/cron.daily
<snip>
lrwxrwxrwx 1 root root 25 Aug 12 21:18 myapp_backup.sh -> /var/www/myapp/backup.sh
</snip>
ls -la /var/www/myapp
<snip>
drwxr-xr-x 2 root root 4096 Aug 13 13:55 .
drwxr-xr-x 10 root root 4096 Jul 12 01:00 ..
-rwxr-xr-x 1 root root 407 Aug 12 23:37 backup.sh
-rw-r--r-- 1 root root 33 Aug 12 21:13 list.txt
</snip>
The file called list.txt is used by backup.sh.
The script just runs tar to create an archive.
From the cron manpage of a debian/ubuntu system:
the files under these directories have to be pass some sanity checks including the following: be executable, be owned by root, not be writable by group or other and, if symlinks, point to files owned by root. Additionally, the file names must conform to the filename requirements of run-parts: they must be entirely made up of letters, digits and can only contain the special signs underscores ('_') and hyphens ('-'). Any file that does not conform to these requirements will not be executed by run-parts. For example, any file containing dots will be ignored.
So:
file need to be owned by root
if symlink, the source file need to be owned by root
if symlink, the link name should NOT contain dots
I had a similar situation with cron.hourly and awstats processing.
I THINK it is related to SELinux and anacron not having the same powers/permissions as cron.
The ACTUAL solution defeated me (so far).
MY WORKAROUND SOLUTION: Run the job via root's cron entries (crontab -e ) and simply schedule it hourly.
With tar, I tried to compress a repository in a chroot environment with ssh, but it failed as it just compressed the symbolic link itself.
How can I compress its content?
-bash-3.00$ ls -ail
1263583 lrwxrwxrwx 1 root root 18 Apr 18 2008 mainwebsite_html -> ../../var/www/html
-bash-3.00$ tar -cjvf archive.tar.bz2 mainwebsite_html
-bash-3.00$ ls -ail
7509101 -rw-r--r-- 1 user1 user1 136 Feb 22 08:57 archive.tar.bz2
1263583 lrwxrwxrwx 1 root root 18 Apr 18 2008 mainwebsite_html -> ../../var/www/html
From the tar(1) man page:
-h, --dereference
follow symlinks; archive and dump the files they point to
Take care of placing the "h" option in the correct place. In your example:
tar -cjvf archive.tar.bz2 mainwebsite_html
should be
tar -chjvf archive.tar.bz2 mainwebsite_html