Normally in linux Debian we do sth like this to install a package non-interactively e.g
sudo apt-get install -y Package_x_z
#[-y --assume-yes]
How we can do the same while installing a perl module e.g
sudo perl -MCPAN -e 'install DBI'
That prompt is (typically) coming from ExtUtils::MakeMaker's prompt() function. Stick export PERL_MM_USE_DEFAULT=1 in your .bashrc (or equivalent for your preferred shell) to stop the prompts. The ExUtils::MakeMaker man page documents it thus:
PERL_MM_USE_DEFAULT
If set to a true value then MakeMaker's prompt function will always return the default
without waiting for user input.
Note that this can come to bite you if you run cpan(1) on a box that's not yet had CPAN repositories configured. It will rattle on and get stuck in a prompt loop at a point where there is no default and you need to make a choice, but have no ability to do so. export PERL_MM_USE_DEFAULT=0 in the shell before running cpan(1) will of course temporarily re-enable input.
To prevent the CPAN client from asking whether to install prerequisites, start it in interactive mode
perl -MCPAN -e shell
and enter the commands:
o conf build_requires_install_policy yes
o conf prerequisites_policy follow
o conf commit
The commit command is optional, but it will update the default configuration, which I suspect is what you want. Without it, you may or may not (depending on whether autocommit is enabled in your CPAN config) need to make this change every time you want to do a prompt-less installation.
These changes will deal with all of the CPAN client's routine questions about whether to install dependencies. For distributions which have questions embedded in their install scripts, you may also want to add
o conf inactivity_timeout 60
to set how long it will wait for a response before automatically going with the default answer to the question. (Set it to 0 to change it back to "wait forever".)
What about just :
$ yes | sudo perl -MCPAN -e 'install DBI'
Ban ! your problem is solved :-)
Appending to an answer here, you can also make these changes in config file located at /usr/share/perl5/CPAN/Config.pm.
'build_requires_install_policy' => q[yes],
'prerequisites_policy' => q[follow],
This helped me to automate installation, since CPAN doesn't have these configuration by default.
Related
MongoDB RPM packages (provided by official repo.mongodb.org repository, as of version 3.4.1) automatically and unconditionally restart server on package upgrade. This behaviour is hardcoded into postun handler:
if test $1 -ge 1
then
/usr/bin/systemctl restart mongod >/dev/null 2>&1 || :
fi
This is an inconvenient and dangerous behaviour, especially when you use configuration management tools to set up your servers. For example, I'd like to run a full Ansible playbook to set up my servers first, and then restart MongoDB manually one by one to have full control of the situation.
Is there any way to alter or disable this? Alternative MongoDB packages, maybe? Or some obscure yum/rpm command option to disable scriptlets?
I'm aware that I can switch to simple .tar.gz installation, but this is the last resort.
If you first download the rpm and install it manually using rpm; you can use the --nopostun option:
rpm -Uvh mongodb***rpm --nopostun
from the rpm man page:
--noscripts
--nopre
--nopost
--nopreun
--nopostun
--nopretrans
--noposttrans
Don't execute the scriptlet of the same name. The --noscripts option is equivalent to
--nopre --nopost --nopreun --nopostun --nopretrans --oposttrans
and turns off the execution of the corresponding %pre, %post, %preun, %postun %pretrans, and %posttrans scriptlet(s).
afaik yumcannot handle the --nopostun and other flags.
I made a perl script to change owner of a file owned by some other user. Script is complete. My administrator save that in /sbin directory and set uid for it using chmod u+s name_of_script. But when I run this script it gives me error that chown operation is not permitted. I made a C program and it works by following same steps. So my question is if setuid is working for perl then I should not get that error because C code did not give me any error. So can i setuid for perl script or I should go with c code.
Don't tell me to ask administrator to change owner each time. Actually in server I have user name staging and I am hosting a joomla site in it. Now when I install some plugin then files related to that plugin are owned by www-data. So that's why I do not want to go to admin each time. Or you can give me some other solution also regarding my problem.
Many unix systems (probably most modern ones) ignore the suid bit on interpreter scripts, as it opens up too many security holes.
However, if you are using perl < 5.12.0, you can run perl scripts with setuid set, and they will run as root. How it works is that when the normal perl interpreter runs, and detects that the file you are trying to execute has the setuid bit set, and it then executes a program called suidperl. Suidperl takes care of elevating the user's privileges, and starting up the perl interpreter in a super-secure mode. suidperl is itself running with setuid root.
One of the consequences of this is that taint mode is turned on automatically. Other additional checks are also performed. You will probably see messages like:
Insecure $ENV{PATH} while running setuid at ./foobar.pl line 3.
perlsec provides some good information about securing such scripts.
suidperl is often not installed by default. You may have to install it via a separate package. If it is not installed then you get this message:
Can't do setuid (cannot exec sperl)
Having said all of that - you would be much better off using sudo to execute actions with elevated privileges. It is much more secure as you can specify exactly what is allowed to be executed via the sudoers file.
As of perl 5.12.0, suidperl was dropped. As a result, if you want to run a perl script on perl >= 5.12.0 with setuid set, you would have to write your own C wrapper. Again I recommend sudo as a better alternative.
No, you cannot use setuid aka chmod +s on scripts. The script's interpreter would be the thing that would actually need to be setuid, but doing that is a really bad idea. REALLY bad.
If you absolutely must have something written in Perl as setuid, the typical thing to do would be to make a small C wrapper that is setuid and executes the Perl script after starting. This gives you the best of both worlds in having a small and limited setuid script but still have a scripting language available to do the work.
If you have a sudo configuration that allows it (as most desktop linux distributions do for normal users), you can start your perl script with this line:
#!/usr/bin/env -S -i MYVAR=foo sudo --preserve-env perl -w -T
Then in your script before you use system() or backticks explicitly set your $ENV{PATH} (to de-taint it):
$ENV{PATH} = '/usr/bin';
Other environment variable that your script explicitly mentions or that get implicitly used by perl itself will have to be similarly de-tainted (see man perlsec).
This will probably (again depending on your exact sudo configuration) get you to the point where you only have to type in your root password once (per terminal) to run the script.
To avoid having to type your password at all you can add a line like this to the bottom of /etc/sudoers:
myusername ALL=(ALL) NOPASSWD:ALL
Of course you'd want to be careful with this on a multi-user system.
The -S options to env splits the string into separate arguments (making it possible to use options and combinations of programs like sudo/perl with the shebang mechanism). You can use -vS instead to see what it's doing.
The -i option to env clears the environment entirely.
MYVAR=foo introduces an environment variable definition.
The --preserve-env option to sudo will preserve MYVAR and others.
sudo sets up a minimal environment for you when it finds e.g. PATH to be missing.
The -i option to env and --preserve-env option to sudo may both be omitted and you'll probably end up with a slightly more extensive list of variables from your original environment including some X-related ones (presumably the ones the sudo configuration considers safe). --preserve-env without -i will end up passing along your entire unsanitized environment.
The -w and -T options to perl are generally advisable for scripts running as root.
I have installed ActivePerl 5.14.2 on a Windows 32 bit machine running XP. My problem is that I'm trying to install a few modules with PPM and it's not working out.
According to ActiveState's website, all you need to do to install a module from their repository is "ppm install module name" , example: http://code.activestate.com/ppm/Template-Toolkit/
Every time I try this or any other module I get: "No Perl script found in input"
Even when I do just "ppm" I get the same message, even though the GUI should run.
When I run PPM with a GUI from the start menu I get this error: "Failed 500 Can't connect to ppm4.activestate.com:8080 (connect: timeout)”
I though that it might be my connection, so using cmd.exe I used the set HTTP_PROXY command and then tried ppm install, but still no luck. So is there any way I can get these modules installed?
Any advice is appreciated !!
Invoke the cpan prompt from your command prompt. Go to cmd and simply type cpan. If you successfully enter cpan prompt them there is probably no issues with your Perl installation. To install a module from cpan prompt just use
cpan>install Module::Name
Screenshot below shows command to install module Net::Stomp
If the above does not work, check if your FTP data and connection ports needs to be added to the Windows firewall exceptions (Ports 20 (FTP Command port) and 21 (FTP Data port)).
Alternatively (if you don't want to add port 20 21 to exception), you can go to the cpan prompt and use an ftp_proxy by
cpan> o conf ftp_proxy http://your.ftpproxy.com
and then issue install command. Or you can update your ../CPAN/config.pm file to make permanent changes to the ftp_proxy parameter.
The next step would be to try set the FTP_PASSIVE mode to 1. By default the libnetcfg configuration for this is set to 0. To change this find libnetcfg.bat file (should be somewhere C:\Perl\bin), open the file in an editor and replace
ftp_int_passive 0
to
ftp_int_passive 1
Again, looking at you r timeout error it seems that your network is blocking you from accessing the CPAN ftp mirrors, this would happen mostly if you are inside a corporate VPN. The solution to this can only be proxy servers.
Attempting to install the Perl module DBD::mysql on Windows 7
From the Windows command line I executed
perl -MCPAN -e 'install DBD::mysql'
Which downloaded and uncompressed the file -- then gave me this ERROR:
CPAN.pm: Going to build C/CA/CAPTTOFU/DBD-mysql-4.018.tar.gz
Set up gcc environment - 3.4.5 (mingw-vista special r3)
C:\PROGRA~1\MySQL\MYSQLS~1.1\bin\MYSQLA~1.EXE: connect to server at 'localhost'
failed
error: 'Access denied for user 'ODBC'#'localhost' (using password: NO)'
Problem running C:\PROGRA~1\MySQL\MYSQLS~1.1\bin\MYSQLA~1.EXE - aborting ...
Warning: No success on command[C:\Perl\bin\perl.exe Makefile.PL INSTALLDIRS=site
]
Guessing the issue is that MySQL's root user has a password, but what's not clear is how I resolve the issue.
Questions, feedback, requests -- just comment, thanks!!
----------
UPDATE (1): RE: force install DBD::mysql
cpan> force install DBD::mysql
Running install for module 'DBD::mysql'
Running make for C/CA/CAPTTOFU/DBD-mysql-4.018.tar.gz
Has already been unwrapped into directory C:\Perl\cpan\build\DBD-mysql-4.018-A
1T8Uh
'C:\Perl\bin\perl.exe Makefile.PL INSTALLDIRS=site' returned status 256, won't
make
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
On other platforms, the build process runs the mysql_config command to get necessary information about the mysql installation without need of a user and password; on win32, if you have a mysql_config command, you have to explicitly tell Makefile.PL about it with a --mysql_config yourpathname parameter. If you don't, it looks for the mysqladmin program and uses its location to determine as much as it can but runs mysqladmin version to get the mysql version. You can provide a user/password for it to be able to do this using --testuser and --testpassword parameters to Makefile.PL.
Following up on "Robert P" comment, I checked the install guide for installing DBD::MySQL in ActivePerl on Win32; on 64, but doesn't appear to have mattered.
Command that did the job was:
ppm install DBD::mysql
The only way I've got round this in the past is a forced install. It always feels like a bodge but I haven't been able to find a better way.
Open up a CPAN shell:
perl -MCPAN -e 'shell'
Then do a force install
force install DBD::mysql
quit gets you back out of the shell.
as ysth said , maybe try this :
cd C:\Perl\cpan\build\DBD-mysql-4.018-A
and run
perl Makefile.PL --testuser validuser --testpassword validpassword
and then try to make - make test - make install,
or its equivalents on windows
I have installed perlbrew which seems like a good solution, but I get some meaningless error when actually trying to install some Perl version:
$ perlbrew install perl-5.12.1
Attempting to load conf from /home/dave/perl5/perlbrew/Conf.pm
Fail to get http://search.cpan.org/dist/perl-5.12.1 (error: ) at /home/dave/perl5/perlbrew/bin/perlbrew line 1277.
Based on your comments do you have http_proxy ENV variable set in your shell?
$ env | grep http_proxy
If not then set it with your proxy settings and re-try perlbrew install:
$ export http_proxy = "http://yourProxyURLorIP:8080"
$ perlbrew install perl-5.12.1
perlbrew uses this ENV variable to pick up the proxy server. If this ENV variable isn't set then it tries the normal direct HTTP connection (see line 1274 in perlbrew current master on Github)
$ua->proxy($ENV{http_proxy}) if $ENV{http_proxy};
If that doesn't work then have a look at HTTP::Lite. This is what perlbrew uses under the hood to fetch source code. NB. perlbrew uses its own copy of HTTP::Lite
Finally if still no luck you mentioned that you "first installed it" via CPAN. The docs does mention issues when upgrading from a previous CPAN version. This maybe something further you need to look into?
Update Test this HTTP::Lite script and let me know what you see (NB. You may need to install HTTP::Lite):
use strict;
use warnings;
use HTTP::Lite;
my $ua = HTTP::Lite->new;
$ua->proxy("yourProxyURLorIP:8080"); # <= http_proxy env minus "http://"
my $req = $ua->request( 'http://search.cpan.org/dist/perl-5.12.1/' )
or die "Unable to get document: $!";
print $ua->body(); # <= if you get this then all is good!
I think you've probably been hit by a known bug with HTTP::Lite, see RT issue uri style proxy env vars fail to set the proxy and port correctly.
The above code is the workaround to this bug. I assume the same bug is in perlbrew copy of HTTP::Lite. If it is then removing the http:// from your http_proxy ENV would resolve the problem (famous last words!)
Update 2
Just to make my last comment clear when you run perlbrew you can do this (from shell like bash):
http_proxy=IPaddr:Port perlbrew install perl-5.12.1
You would need to always prefix every perlbrew command like this, at least until HTTP::Lite or perlbrew proxy bug is fixed.
Alternative to above is you can just patch your local version just be adding the following before line 1277:
$ENV{http_proxy} = "IPaddr:Port"; # <= your proxy IP & port
Hopefully we've finally cracked it! Let me know if all successful because if so then I'll post a fix to Gugod (author of perlbrew) with necessary local changes to HTTP::Lite.