So I am following this guide: http://technotes.1000lines.net/?p=23 and I am going through the steps. I have a VPN (slicehost.com) with Debian Etch, serving a website (static so far) with nginx. I used wget to download FastCGI and I did the usual make make install routine.
So I guess since FastCGI can't normally run CGI scripts you have to use some type of perl wrapper to interpret the perl.
Now I run this script
http://technotes.1000lines.net/fastcgi-wrapper.pl
and I run into the exact same problem that a person ran into on the page that the script was submitted:
http://www.ruby-forum.com/topic/145858
(I'm not a ruby person and there is nothing ruby oriented in there)
I keep getting a
# bind/listen: No such file or directory
And I have no idea how to proceed. I would appreciate any help and I can give any more details that anyone would need.
The webserver needs a Unix domain socket to connect to the FastCGI application, but the socket can't be created. Most likely the directory you want it to be in doesn't exist (because they are automatically created when you do a bind).
Leon is exactly correct. There are two prerequisites for allowing the socket to listen:
Make sure the socket directory exists.
This is defined in the fastcgi-wrapper.pl script as /var/run/nginx/perl_cgi-dispatch.sock. Therefore, you will need to make sure /var/run/nginx exists.
Make sure the socket directory is owned by the same user that the fastcgi-wrapper.pl is being executed as.
I'm gonna try and "water down" fastcgi-wrapper.pl, so it can be used with spawn-fcgi.
I use two of those sockets allready:
spawn-fcgi -C 3 -u www-data -s /var/run/php-fcgi.sock -P /var/run/php-fcgi.pid -- /usr/bin/php5-cgi
spawn-fcgi -F 3 -u www-data -s /var/run/lua-fcgi.sock -P /var/run/lua-fcgi.pid -- /usr/bin/wsapi.fcgi
Inside /var/run I have:
-rw-r--r-- 1 root root 14 2010-08-07 12:14 /var/run/lua-fcgi.pid
srwxr-xr-x 1 www-data www-data 0 2010-08-07 12:14 /var/run/lua-fcgi.sock=
-rw-r--r-- 1 root root 4 2010-08-07 12:14 /var/run/php-fcgi.pid
srwxr-xr-x 1 www-data www-data 0 2010-08-07 12:14 /var/run/php-fcgi.sock=
I can easily start and stop the FastCGI wrappers, and I want to do that with Perl too.
If anyone has already a script, that works with spawn-fcgi, I'd be happt to use that, or at least have a look at it.
Cheers,
--polemon
Related
I am new to Perl. I'm building a plugin for Cpanel to install SSL certificates when the user clicks an option.
I have to execute a command as root inside the Perl code. How can I do this?
So basically you need to run a system command as root user from within a Perl script.
You can use the system built-in function with a sudo inside it. This will fork a new process where the command will be executed while the parent process waits, and then return the exit status of that command.
For example, this basic command switches to root and prints the current user :
perl -e 'system("sudo su -c whoami")'
Obiously, it outputs this on the standard output :
root
Notes :
for this to work, you need you application user to be able to switch to root(without the need of typing a password) ; some could consider that a security breach (some attacker that would have taken over your application would be able to cause fatal damage to your system)
the actual command to switch to the root user might vary depending on your OS ; the one I used in the example you is for RedHat
I searched the CPAN for modules that provide the "switch to root" functionality and the only one I found is Sudo ; I didn't try it, but it that was not updated since 2013 and has few issues pendings since 3 to 9 years
I am trying to correct the following stunnel syntax for CentOS 6.x:
stunnel -c -f -d 1143 -r imap.foo.tld:993 -P ''
The proposed syntax of is not working:
-c: No such file or directory (2)
To take care of XY problem concerns: I need to migrate my IMAP email from Host A to Host B. Generally I use imapcopy and port 143. However this time host A only supports SSL 993, which imapcopy does not. Stunnel is supposed to get around this, at least according to this tutorial: http://manurevah.com/blah/en/p/Migrate-emails-with-Imapcopy
That page contains a note (unfortunately not very well called out) that is of relevance.
NOTE: Stunnel doesn't work the same way since Debian Jessie (not sure since which version of stunnel). I've not dug in to it and hence do not know what the new syntax should be (if you know, let me know).
I don't know how you found that page but it is clearly old and out of date. (I can only find one other page that references stunnel having command line arguments like that and it lists itself as old more explicitly. Everything else I can find is about the new config file based configuration.)
You could also use pymap-copy instead imapcopy. It's more state of the art and you don't need stunnel.
Or you can write:
stunnel3 -c -f -d 1143 -r imap.foo.tld:993 -P ''
stunnel3 is a wrapper script for backward compability
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 a problem when i want to install perl module
I make " cpan" to install cpan , but i get this "
Terminal does not support AddHistory.
Your configuration suggests that CPAN.pm should use a working
directory of
/home/cyrine/.cpan
Unfortunately we could not create the lock file
/home/cyrine/.cpan/.lock
due to permission problems.
Please make sure that the configuration variable
$CPAN::Config->{cpan_home}
points to a directory where you can write a .lock file. You can set
this variable in either a CPAN/MyConfig.pm or a CPAN/Config.pm in your
#INC path;
You don't seem to have a user configuration (MyConfig.pm) yet.
i make "y"
then i got this strange message :
mkdir /home/cyrine/.cpan/CPAN: Permission denied at /usr/share/perl/5.10/CPAN/Shell.pm >line 656
Any idea please?
Thank you
The immediate cause of this problem is that you don't have write permissions on /home/cyrine/.cpan. In my experience, this is most often the result of logging in as a normal user, then running cpan for the first time on that account in a su session, causing the CPAN configuration to be created in ~cyrine (because you have cyrine's environment), but owned by root (because su has given you root's permissions). Assuming that is the case, you should be able to resolve this my suing to root, running the command chown -R cyrine.cyrine /home/cyrine/.cpan and then running cpan as user cyrine.
I am trying to write a script for starting tomcat server which get disassociated from the shell once the execution of the script complete. For example please see below snapshot of the screen.
bash-3.00# ./startup.sh
Using CATALINA_BASE: /opt/tomcat/6.0.32
Using CATALINA_HOME: /opt/tomcat/6.0.32
Using CATALINA_TMPDIR: /opt/tomcat/6.0.32/temp
Using JRE_HOME: /opt/jdk1.6.0_26/
Using CLASSPATH: /opt/tomcat/6.0.32/bin/bootstrap.jar
bash-3.00# ps -eaf | grep tomcat
root 4737 2945 0 02:45:53 pts/24 0:00 grep tomcat
root 4734 29777 1 02:45:42 pts/24 0:19 /opt/jdk1.6.0_26//bin/java -Djava.util.logging.config.file=/opt/tomcat/6.0.32/c
Now as you can see that once the execution of the script complete the tomcat process is associated with pts/24 till I close the shell.
But what I want is that even if the shell is kept open the process should show a behavior like below
bash-3.00# ps -eaf | grep tomcat
root 13985 2945 0 22:40:13 pts/24 0:00 grep tomcat
root 13977 29777 1 22:40:01 ? 0:22 /opt/jdk1.6.0_26//bin/java -Djava.util.logging.config.file=/opt/tomcat/6.0.32//
The operating System is Solaris. The various option I used to accomplish the same are using nohup, and disown but still the process is associated with shell.
The other mechanism is to put in crontab or use svc to make the process start as system comes up i.e. daemon or we can write a small C program which forks a process and goes away.
Here please note that the process is running in background.
But I want to achieve the same using a shell or perl script. So any thought on the same will help me a lot.
Thanks in advance.
Well, you could go and do all the hard work yourself, but why when there's a module for that: Proc::Daemon (Not sure if it works on solaris)
The documentation also describes the process used, which is useful for you to understand anyhow, if you decided to go ahead and craft your own daemonizing code.
( nohup ./script.bash & )
The parenthesized sub-shell exits immediately and ps -ef |grep script.bash returns:
501 59614 1 0 0:00.00 ttys005 0:00.00 /bin/bash ./script.bash