[SOLVED] Sending Mail with pfSense
-
I'm hoping someone can give me a hit as to how I can send email from a script on pfSense
using the built in notification system. (i.e. using the credentials set up in
System / Advanced / Notifications and not having to specify this info in the script. -
Use the mailreport package.
-
Thanks for the reply… checked that out, but unfortunately it is cron based and sends an email even if there is nothing to send.
I'm looking for emails as response to conditions.
I don't mind running a jobs that do nothing, but I don't want to fill up my email box with them.
-
I'm hoping someone can give me a hit as to how I can send email from a script on pfSense
using the built in notification system. (i.e. using the credentials set up in
System / Advanced / Notifications and not having to specify this info in the script.Try this:
cat /etc/hosts | /usr/local/bin/mail.php -s"Subject here"
-
Try this:
cat /etc/hosts | /usr/local/bin/mail.php -s"Subject here"
Thanks… that works great as long as it's run from root.
Just wondering if anyone can tell me if there is a way that I can run as a user with less permissions.
I have created a user (at this point only permission is shell access) which I use to run my custom scripts.
If possible, I'd like to be able to use a low privilege user. -
I have created a user (at this point only permission is shell access) which I use to run my custom scripts.
If possible, I'd like to be able to use a low privilege user.Maybe sudo ? It's available on pfSense repository.
-
I have created a user (at this point only permission is shell access) which I use to run my custom scripts.
If possible, I'd like to be able to use a low privilege user.Maybe sudo ? It's available on pfSense repository.
Thanks… I thought of that, but if possible I'd rather not have any route to root at all if possible.
-
Try this:
cat /etc/hosts | /usr/local/bin/mail.php -s"Subject here"
Thanks… that works great as long as it's run from root.
It works from non-root if secure SMTP (SSL/TLS) is not in use. If secure SMTP is in use, you will encounter this defect:
https://redmine.pfsense.org/issues/6686
A fix can be found here:
https://forum.pfsense.org/index.php?topic=115349.msg646466#msg646466
-
Try this:
cat /etc/hosts | /usr/local/bin/mail.php -s"Subject here"
Thanks… that works great as long as it's run from root.
It works from non-root if secure SMTP (SSL/TLS) is not in use. If secure SMTP is in use, you will encounter this defect:
https://redmine.pfsense.org/issues/6686
A fix can be found here:
https://forum.pfsense.org/index.php?topic=115349.msg646466#msg646466
Thanks for the reply…. I looked at the post you referred me to, but I don't know how to apply the patch. Is the entire contents of the code box the patch, or are the first 2 or 3 lines informational output only?
The core issue turns out to be an file permission issue with one of the php ini files, /usr/local/etc/php/extenstions.ini. The file is owned by root and created with permissions 600, which prevents it from being read by the user upsmon runs as (uucp).
This file is being removed in pfSense 2.4, so the issue should be resolved then. If you want to correct the issue in the interim, you can apply the following patch:
*** /etc/rc.php_ini_setup.org Thu Jul 14 18:14:42 2016 --- /etc/rc.php_ini_setup Tue Aug 9 11:58:33 2016 *************** *** 102,107 **** --- 102,108 ---- fi /usr/bin/sort -u -o /usr/local/etc/php/extensions.ini /usr/local/etc/php/extensions.ini + chmod 644 /usr/local/etc/php/extensions.ini # Set upload directory if [ "$PLATFORM" = "nanobsd" ]; thenNote that you cannot just change the permissions on /usr/local/etc/php/extensions.ini because it is recreated at every boot.
Can someone please give me some guidance as to what I need to do and where I need to store the patch info. I'm not even sure what to google to find out.
Thanks…
-
It's a standard patch format, the output of a contextual diff command (diff -c). It shows one line being added (+), which is the chmod.
If you are not experienced/comfortable with these things, please be very careful. Research and understand the changes you want to make before editing critical system files such as this one. It's easy to make a mistake and end up with a non functional system.
-
It's a standard patch format, the output of a contextual diff command (diff -c). It shows one line being added (+), which is the chmod.
If you are not experienced/comfortable with these things, please be very careful. Research and understand the changes you want to make before editing critical system files such as this one. It's easy to make a mistake and end up with a non functional system.
Thanks for the reply… I saw the chmod, but I wasn't sure about the other lines.
I understand that patches need to be handled with great care, and aren't likely going to be something that I do without input from experienced users/devs.
In this case I know why, I'm doing it, have a general idea of what it's doing, and I'm assuming that you know what you are doing and have tested it.
I've installed the patch management package, and it looks like the mechanics of applying the patch shouldn't be too difficult with a bit of guidance.
Question 1: Do I copy the entire code block in to the "Patch Contents" block, or do I have to edit some of it out?
Question 2: How do I complete the following "Patch Application Behavoir" fields?
Path Strip Count (Defaults to 1)
The number of levels to strip from the front of the path in the patch header.Base Directory (Defaults to /)
Enter the base directory for the patch, default is /. Patches from github are all based in /.
Custom patches may need a full path here such as /usr/local/www/.Ignore Whitespace
Ignore whitespace in the patch.Question 3: Am I correct in assuming that "Auto Apply" should NOT be checked because this patch won't be required when the 2.4 release comes out?
Auto Apply
Apply the patch automatically when possible, useful for patches to survive after updates.If a 2.3.3 comes out then I'll have to check into things before applying it.
Thanks in advance for having patience with a noob.
-
I'm afraid I can't guide you much on the patch management package as I've never used it.
-
I installed the package.
1. Yes, the entire code block
2. Defaults are fine: Path Strip Count 1, Base Directory /, Ignore Whitespace (doesn't matter)
3. Auto Apply is as you prefer. If the context doesn't match, it won't apply. In this case, I would leave it off because the fix is already in the 2.3 code base, so the patch won't be necessary if a 2.3.3 is released. Neither will it be needed with 2.4.
Note that you will need to reboot after installing the patch for it to take effect.
-
Put the patch into the System Patches package and got the following output when I did "Test":
Patch can be applied cleanly (detail)
Patch Test Output apply /usr/bin/patch --directory=/ -t -p1 -i /var/patches/57aff654da9b3.patch --check --forward --ignore-whitespace Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /etc/rc.php_ini_setup.org Thu Jul 14 18:14:42 2016 |--- /etc/rc.php_ini_setup Tue Aug 9 11:58:33 2016 -------------------------- Patching file etc/rc.php_ini_setup using Plan A... Hunk #1 succeeded at 102. donePatch can NOT be reverted cleanly (detail)
Patch Test Output revert /usr/bin/patch --directory=/ -f -p1 -i /var/patches/57aff654da9b3.patch --check --reverse --ignore-whitespace Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /etc/rc.php_ini_setup.org Thu Jul 14 18:14:42 2016 |--- /etc/rc.php_ini_setup Tue Aug 9 11:58:33 2016 -------------------------- Patching file etc/rc.php_ini_setup using Plan A... Hunk #1 failed at 102. 1 out of 1 hunks failed while patching etc/rc.php_ini_setup doneI'm not sure if there is anything I need to do, or if it is safe to apply this patch. I believe what the system is telling me is that this is a one way street and there is not reversal possible. Can someone please clarify.
Thanks…
-
Yes, it's safe.
What the test output is telling you that the patch can't be reverted (currently). This is because the patch hasn't been applied yet. After the patch is applied, the test results will flip–it will say it cannot be applied but can be reverted.
-
Thanks very much dennypage!
For the benefit of anyone reading this thread, this patch solves the problem…
You can now send mail from a non-root account without any sudo or other privilege escalation.
