How to retain the file attributes uid and gid when copy the file from remote using Net::SFTP::Foreign module? - perl

I am using Net::SFTP::Foreign module to copy the files from remote to some source machine and after copy operation, able to retain the file creation time and permissions except the gid and uid.
After copy operation I have below attributes:
root#system # ls -n
/dest/files -rw-r--r-- 1 0 0 4424 Jun 10 04:45 /dest/files/file.txt
While at source the attributes are:
root#source # ls -n
/source/files -rw-r--r-- 1 1001 1002 4424 Jun 10 04:45 /source/files/file.txt
I used below code for SFTP operation:
my $sftp = Net::SFTP::Foreign->new(
host => $host
);
$sftp->get( $file, $dest, copy_perm => 1)
I have not found any option in documentation of Net::SFTP::Foreign for retaining the uid and gid.
Is anybody has any idea?

Related

How to set correct file permissions with CGI::Session

For anyone else reading this; it seems the issue was caused by permissions and suexec was part of the issue. Having disabled suexec, all is well again (subject to consequential issues I may find later).
Two files I have in (say) dir1, in /cgi-bin/dashboard-login/ and they use CGI::Session to manage the session.
Both files set a new session like this:
my $session = new CGI::Session(undef, $cgi, {Directory=>"$sessions_dir_location"}) or die CGI::Session->errstr;
This means the second file is actually opening the session created by file1. All good so far.
File 3 is in the same sub-domain but in a different dir (/cgi-bin/dashboard/). It also runs that session string but I get the following error:
Software error:
new(): failed: load(): couldn't retrieve data: retrieve(): couldn't open '/var/www/vhosts/example.com/sessions_storage/cgisess_fc6c62eee135f6cd418defef4516a59c': Permission denied at index line 38.
For help, please send mail to the webmaster (root#localhost), giving this error message and the time and date of the error.
In Filezilla, I see that the file permission is set to "dfr (0640)" for the latest session file but, the previous one has the permissions "adfr (0640)" That adfr file can be opened in filezilla and didn't have any issues when I ran my scripts. Now the session files are being created as "dfr (0640)". IS there a way to set the server (or the CGI::Session), to apply "adfr (0640) permissions?
And, in your experience, is that the likely cause of the problem?
Here you go Håkon Hægland
ls -l /var/www/vhosts/myDomain.com/sessions_storage
-rw-r-----. 1 MyUserName psacln 166 Jan 26 01:22 cgisess_0741489d1010b7ab36f86420e5c58e84
-rw-r-----. 1 apache apache 1769 Jan 26 12:35 cgisess_2d475576f960f6c5407d7a273c02ead1
ls -l /var/www/vhosts/domainName.com/subDomain.myDomain.com/cgi-bin/dashboard-login
-rwxr-xr-x. 1 MyUserName psacln 30628 Jan 26 01:46 login.pl
-rwxr-xr-x. 1 MyUserName psacln 48391 Jan 26 00:49 login-with-pin.pl
ls -l /var/www/vhosts/domainName.com/subDomain.myDomain.com/cgi-bin/dashboard
-rwxr-xr-x. 1 MyUserName psacln 40742 Jan 24 17:47 web_content_manager
For anyone else reading this, it was a permissions issue. It seems to relate to SuExec. Having disabled SuExec, temporarily, until I learn more about directory locations and permissions fully, all is well again.

Postgresql could not load library

after days of regular fight with postgis I stuck on this:
postgres=# CREATE EXTENSION postgis; ERROR: could not load library
"/usr/pgpro-9.6/lib/rtpostgis-2.4.so": libgdal.so.20: cannot open
shared object file: No such file or directory
and have no idea how to pass it, because library path is correct...
[combat#urpordfinal ~]$ ls -alt /usr/pgpro-9.6/lib/ total 13080
-rwxr-xr-x 1 root root 1440056 Apr 23 11:52 postgis_topology-2.4.so
drwxr-xr-x 5 root root 8192 Apr 23 11:52 .
-rwxr-xr-x 1 root root 1878728 Apr 23 11:52 rtpostgis-2.4.so
I'm running pgsql 9.6.8 and psotgis build from source
You have to make sure that libgdal.so.20 is on the shared library path.
Find out where the library is and add that directory to the shared library path.
On Linux, you would normally do that by adding the directory to /etc/ld.so.conf (or, better, to a PostGIS configuration file in /etc/ld.so.conf.d) and running ldconfig.

Maintain executable file permissions when uploading binaries to a github release

I'm adding binaries to a release in github by dragging and dropping them into the binaries upload section when creating a new release. The binaries have the following permissions on my local (OSX):
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file1
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file2
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file3
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file4
However when I download the binary from Releases the file mode has changed:
-rw-r--r--# 1 user group 100 Mar 22 09:00 file1
Has this been documented anywhere? Is there a way to preserve file permissions when uploading binaries to github?
Is there a way to preserve file permissions when uploading binaries to github?
I don't believe so. People that download the file will need to chmod +x to get the execute permission back. A file's permission is not stored within the file itself, rather it is an attribute of the file on the file system.
If you really need to preserve complex permissions for files, I would suggest storing the files in a container that preserve permissions. Like a DMG for macOS, and uploading the DMG instead.

lb web-client export always using /tmp directory

In my lb-web-server.config file I have set the following:
[handler:delimited-file]
classname = com.logicblox.bloxweb.delim.DelimitedFileHandler
tmpdir = /my/temp/dir
When I run an export with lb web-client export --no-compress --output /some/dir/myfile.csv http://service-uri a temporary file is created in /my/temp/dir, but several files are also written to /tmp:
-rw-r--r--. 1 root root 109M Oct 9 12:13 tmp21498_2316_XXYMElJ4
-rw-r--r--. 1 root root 106M Oct 9 12:13 tmp21498_2317_XXTHg8fE
-rw-r--r--. 1 root root 114M Oct 9 12:15 tmp21498_2318_XXQhuWvW
-rw-r--r--. 1 root root 106M Oct 9 12:15 tmp21498_2319_XX7KbYmo
When the combined size of these temp files exceeds the available space on /tmp, the export fails.
Am I missing an additional setting in lb-web-server.config which would cause these files to be written to the correct location?
I think you can avoid storing these temp files under /tmp by setting the LB_TEMPDIR environment variable to another directory.
It would appear the runtime is using "generic" temporary files, whose location is controlled by the environment variable LB_TEMPDIR (defaulting to /tmp). I'm not aware of any config file setting to control it, unfortunately.
I will file a bug.

In Solaris server with Putty, unable to delete copied file with some irregular special character

I use putty to log in to a solaris server. while i was performing a copy operation I pressed left arrow key to edit the file name but it kept adding this character ^[[D desperate I pressed return key and the copy operation got complete
cp temp.jar temp.jar^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D
I was planning to rename is as temp.jar.test, I used 'ls' command to check what has happened and to my surprise two files came up with same name!
root[dev1]# ls -lt temp*
-rw-r--r-- 1 root other 488554 Apr 11 02:25 temp.jar
-rw-r--r-- 1 root other 488554 Apr 11 02:22 temp.jar
-rw-r--r-- 1 root other 488554 Apr 11 02:22 temp.jar.041114
-rw-r--r-- 1 root other 488487 Sep 30 2013 temp.jar.032514
and I used 'rm' command to delete, the original file got deleted but the file copied with ^[[D character is not getting deleted. And I'm getting a msg like 'eisvr.jar.: No such file or directory'
Help me delete the file. I tried issuing 'rm temp.jar^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D'. It resulted in more errors.
The simplest way would be to run this command:
rm -i temp.jar?????????*
and answer yes when prompted to remove the bogus one.