I just started this thread, because I noticed sometime problems with my additional installation of FHEM within my IPFire installation. This happens, when permissions or other things changed within the IP Fire installation, which I have to handle in my additional installation.
I get the hint, that it will be better to use the user “nobody” instead of the own additional user, which can be a security leak as well.
Here are the first Items I have to change:
User in my start/stops scripts within “init.d”/rc0.d/rc3.d/rc6.d
You can use your own additional user if you need to but if you want to use something like the dma mail system then you will need to run that mail command as the user nobody.
The security benefits come because the user nobody does not have logon privileges but you can also set that up for any additional user you create. You just set the login shell to /bin/false instead of /bin/bash
However using the user nobody is also a good approach if your FHEM program allows it. I am not familiar with it to be able to say. You will have to try it and see how it works.
You can’t login as nobody because that user does not have a login shell. In IPFire the perl files are all owner:group root:root. If you have them set as nobody:root then with permissions of 755 the root user will be able to read them and execute them but not write to them.
Probably the simplest approach is to run
sudo -u nobody nano "filename to edit"
Replace nano with the editor you are using on your system. This then changes you to the user nobody for that command and when you exit you go back to being your regular user.
I just had a quick read through some of the pages on the FHEM website. If I was looking at using this software then I would install it on a RPi and put it in the Orange zone of IPFire rather than installing on IPFire directly. It would save on any concerns about interactions between FHEM and IPFire.
If you stay on IPFire then I found the page where it shows the fhem user creation which has the shell set as /bin/false That user definition seems a reasonable one to me and if using mail from IPFire is the only aspect of IPFire that you need to use then I would leave your FHEM setup with that user and only change the mail command in FHEM to be run as user nobody so that dma will accept it.
up to now I installed the following function, which sends email via sendmail
sub DebianMail
{
my $to = shift;
my $subject = shift;
my $message = shift;
my $from;
my $msg;
$from = “<emailaddress@myProvide.de”;
$msg = MIME::Lite->new(
From => $from,
To => $to,
Subject => $subject,
Type => ‘multipart/mixed’
) or die “Error creating multipart container: $!\n”;
### Add parts (each "attach" has same arguments as "new"):
$msg->attach(
Type => 'TEXT',
Data => $message
) or die "Error adding the text message part: $!\n";
$msg->send_by_sendmail;
return;
}
The function works well, I only get a message within the logfile "“error closing /usr/sbin/sendmail: No child processes (exit -1)”. But the mail is send !
I noticed, that the perl file ( within ipfire will have switch off warnings. So I do not know,
if this problem is also shown in ipfire by call this function.
here the lines from mail.cgi
#enable only the following on debugging purpose #use warnings; #use CGI::Carp ‘fatalsToBrowser’;
My function is based on the function “sub testmail { …}”.
But I will also check at the weekend, to change the system to the user “nobody”.
An additional PI is not a option for me, because I already had this before and It will consume
more power (bur I would like to save power).
I just try to get a little bit closer to the problem of the "error closing /usr/sbin/sendmail: No child processes (exit -1)" log
The eMail will be send, but the complete perl module will be completely aborted.
Any additional functions, even below the function call of the “DebiaMail” will not executed.
What type of MIME:Lite is IP fire using. I have read, that this module is no longer maintained and your should use other functions to send emails.
Can you confirm this, Or did you maintain this version of MIME:Lite ?
Where is this module located in the source code of IP fire. I did not find it.
The developer says that he recommends using other perl modules. However one of the modules he recommends was last updated in 2017, one at end of 2020, leaving one from July 2021 and the MIME-Lite module from June 2021.
It may well be something that needs to be done to change to another perl module for this but then someone has to do the work to rewrite the places that currently use the existing module to match up with the different interface for whichever other module is selected.
I am sure the IPFire devs would be happy if someone would be willing to help by putting a patch together to do the above.
I have already updated the system in matter of the user “nobody” and the system is
running well with this setting.
But when is restart the service of fhem, the system does not get a connection to
the “/dev/ttyACM0” and “/dev/ttyACM1” which is used for the communication to the
sensors. After a reboot it works fine.
I have no clue, why this happen. Maybe, if I did not find the reason for this, I will switch
back to the additional user again.
Also the warning message is still shown and the function is aborted after sending a email. Even
with the user “nobody”. I will try to check this within the perl file of the MIME:Lite. But I have to say, I am not a specialist of perl.