Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    NUT notifications not working on pfsense+

    Scheduled Pinned Locked Moved General pfSense Questions
    50 Posts 5 Posters 22.4k Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • dennypageD Offline
      dennypage @Austin 0
      last edited by

      @austin-0, @pdavis I have a PR in which will restore notification functionality. You can find it here if you want to follow it, or if you just want to grab the revised version of nut_email.php.

      GertjanG P Austin 0A 3 Replies Last reply Reply Quote 1
      • GertjanG Online
        Gertjan @dennypage
        last edited by

        @dennypage said in NUT notifications not working on pfsense+:

        You can find it here if you ...

        0a2a5958-bf5e-4d02-af84-8cb10583f3e9-image.png

        The GUI says :

        c1b51c37-2042-4a93-8776-8ba6df48c302-image.png

        So, the user would except that email and/or Telegram and or Pushover works.

        The file is called :

        /usr/local/pkg/nut/nut_email.php
        

        Your edit makes notifications 'email' only (no more Telegram/Pushover).
        Are you sure ?

        @pdavis
        I propose a plan B : take control of things yourself everything :

        Enable notifications".

        Place this in the "Additional configuration lines for upsmon.conf" :

        NOTIFYFLAG ONLINE   SYSLOG+WALL+EXEC
        NOTIFYFLAG ONBATT   SYSLOG+WALL+EXEC
        NOTIFYFLAG LOWBATT  SYSLOG+WALL+EXEC
        NOTIFYFLAG FSD      SYSLOG+WALL+EXEC
        NOTIFYFLAG COMMOK   SYSLOG+WALL+EXEC
        NOTIFYFLAG COMMBAD  SYSLOG+WALL+EXEC
        NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
        NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC
        NOTIFYFLAG NOCOMM   SYSLOG+WALL+EXEC
        NOTIFYFLAG NOPARENT SYSLOG+WALL+EXEC
        NOTIFYCMD /usr/local/sbin/upssched
        RUN_AS_USER root
        

        Note the line "NOTIFYCMD /usr/local/sbin/upssched"

        Now, continue reading here NUT upssched - read the entire thread for more info.

        In short : "upssched" ( /usr/local/sbin/upssched) is the NUT event scheduler.
        It has a config file here /usr/local/etc/nut ( not surfaced in the GUI !) called upssched.conf.

        [23.01-RELEASE][admin@pfSense.near.by]/root: grep -v '^#' /usr/local/etc/nut/upssched.conf
        
        CMDSCRIPT /usr/local/bin/upssched-cmd
        

        The file has to be edited, as shown in the thread I've shown above.
        With this file you can handle all possible event, and have pfSense do its thing.

        Like calling :

        send_smtp_message($MSG, $subject);
        

        and/or

        @notify_all_remote($subject . " - " . $MSG
        

        Just a reminder : when updating NUT, it is very possible that the file "/usr/local/bin/upssched-cmd" gets over written by a default 'do nothing" file.
        You'll have to copy in place your own version again.
        This can be done using a mode made "patch" or a mere straightforward 'cp' upon boot (use the Shellcmd package, and write up your own copy command, from /root/upssched-cmd to /usr/local/bin/upssched-cmd

        The pro's : using NUT as it was meant to be used.
        Con's : more maintenance.

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        dennypageD 1 Reply Last reply Reply Quote 1
        • dennypageD Offline
          dennypage @Gertjan
          last edited by

          @gertjan Thank you for pointing that out. I have clarified the text.

          I stopped using or recommending upssched years ago. The NUT documentation does not particularly recommend its use anymore either. While upssched is useful for supporting very complex situations, the level of complexity generally just gets the average user in trouble. It's an advanced / experts only tool, and not a good choice for a firewall package where the goal is simplicity and reliability.

          FWIW, using upssched would not actually address the problem. The problem is that notify_all_remote() now requires root privileges to function. Yes, I could have simply addressed the issue by requiring upsmon be run as root (no need for upssched), but I am not comfortable with making that a requirement.

          As it sits right now, other than smtp, there is no standard notification system available in pfSense 23.01+ that does not require root privilege to initiate. If one is added, I will move to it when it becomes available. But in the interim, I am going with the same approach that the other non root packages have gone with, which is send_smtp_message().

          GertjanG 1 Reply Last reply Reply Quote 0
          • P Offline
            pdavis @dennypage
            last edited by

            @dennypage Thank you, Denny! I will follow the PR

            1 Reply Last reply Reply Quote 0
            • dennypageD Offline
              dennypage
              last edited by

              @pdavis You are most welcome

              1 Reply Last reply Reply Quote 0
              • GertjanG Online
                Gertjan @dennypage
                last edited by

                @dennypage

                If I understand correctly, you have to use "send_smtp_message()" because :

                @notify_all_remote($subject . " - " . $message);
                

                which is nothing more then :

                function notify_all_remote($msg) {
                        notify_via_smtp($msg);
                        notify_via_telegram($msg);
                        notify_via_pushover($msg);
                        notify_via_slack($msg);
                }
                

                needs root facilities for telegram, pushover and slack but not smtp ?
                Humm, that's more a s pfSense as a NUT issue for me then IMHO.

                But I do get this :

                a61d2c8b-aa0e-4887-b0a3-f79e3c1da31e-image.png

                My 'signal system' runs as root, so I never had any issues when sending mail - as the sched script handles all this.

                Btw : I don't mind your package runs as root ๐Ÿ˜Š

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                dennypageD 2 Replies Last reply Reply Quote 0
                • dennypageD Offline
                  dennypage @Gertjan
                  last edited by

                  @gertjan said in NUT notifications not working on pfsense+:

                  f I understand correctly, you have to use "send_smtp_message()" because @notify_all_remote($subject . " - " . $message);
                  needs root facilities for telegram, pushover and slack but not smtp ?
                  Humm, that's more a s pfSense as a NUT issue for me then IMHO.

                  Yes, it is a general pfSense issue. notify_all_remote() manages smtp notifications via a queue, and that queue management now requires root privilege. Detailed discussion in the Redmine issue. Unfortunately, with the change (update #15) any use of notify_all_remote to send smtp by a non root will silently fail.

                  In my reading of the code, the queue only exists to suppress duplicate sends for smtp messages. It suppresses notices if the new notice is exactly the same as the prior notice sent (not the prior notice queued). I don't really see a lot of value in that, so I would have probably solved the spamming problem by simply deleting the whole duplicate suppression system. But it wasn't my code to fix, and there doesn't seem to be much interest in discussing alternative solutions, so I took the approach of bypassing the queue code and sending smtp directly as others have done.

                  GertjanG 1 Reply Last reply Reply Quote 0
                  • dennypageD Offline
                    dennypage @Gertjan
                    last edited by

                    @gertjan, you motivated me to make a proposal.

                    1 Reply Last reply Reply Quote 0
                    • GertjanG Online
                      Gertjan @dennypage
                      last edited by Gertjan

                      @dennypage

                      I'm aware of issue #14032 and didn't understand what was wrong / I couldn't reproduce it / was using the NUT package for years.
                      The why part is now clear to me : I'm handled the 'signalling part' myself by using the complicated upsched. And did the 'bad-behavior' thing that masks the issue : I run the CMD script as root.
                      Now, I get it.

                      About your note #25 :
                      I agree with "Processes and tasks that do not need root, should not run as root",
                      but I would silently add a

                      RUN_AS_USER root
                      

                      at the top of this part, where upsmon.conf is created.

                      Add a

                      # To be removed when "/usr/local/pkg/nut/nut_email.php" doesn't need root anymore
                      

                      ๐Ÿ˜Š

                      No "help me" PM's please. Use the forum, the community will thank you.
                      Edit : and where are the logs ??

                      1 Reply Last reply Reply Quote 0
                      • Austin 0A Offline
                        Austin 0 @dennypage
                        last edited by Austin 0

                        @dennypage I have fetched patch, but there is no apply option. If I am not mistaken I believe that usually happens because of some incompatibility. I have an SG-1100 running pfsense 23.01. For the time being I have added the configuration change to make it run as root. I have tested this, and I am happy to report that it is working.

                        dennypageD 1 Reply Last reply Reply Quote 0
                        • dennypageD Offline
                          dennypage @Austin 0
                          last edited by

                          This has been moved to a new Redmine issue.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.