As Ysul will be superseded by Windriver, this task will need to be reevaluated.

For cost optimization, as the final decision was made this Monday, we were waiting for Black Friday promotion.
Purchase has been done for a PRO-6-S (Intel Xeon E3-1240-V6, 64 GB DDR4 ECC, 2x 500 GB SSD).

12.0 done at an not logged date (probably 33 days ago, ie 2016-10-17), I assume this is 12.1 request per comment.

No more log messages.

Known similar issue: https://forums.freebsd.org/threads/crontab-not-working-after-upgrading-to-freebsd-12-0-release.68675/

12.1 is coming in November, according https://www.freebsd.org/releases/12.1R/schedule.html

Installed, reboot for kernel live 2019-08-24.

https://github.com/freebsd/pkg/blob/master/libpkg/repo/binary/init.c#L334 makes me notice pkg wasn't invoked as root.

https://packages.nasqueron.org/freebsd/ works fine

I have no idea how to do it, but looks like a good plan. Apart that, in my opinion, you do a much more of what would be necessary to run nasqueron services (but it is your time, you use it like you want)

Those are valid concerns.

looks an interesting tool, something quite frightening is that it comes with a set of exploit, (if I understand, a common way to exploit sudo flaws).
As a shell script not even indented, it is absolutely unreadable, and more or less one have to trust the creator to not making mistake.
Moreover for full use, you have to give a sudo password in clear text ( I just don't understand the reason)
As such, I would say it would be kind of crazy to run it automatically and I would not comfortable to simply run it for myself in any way.

Tagging security as we could need follow-up ACL to allow to connect to.

It's provided by PSmisc.

Temporarily hotfixed with ln -s /usr/local/lib/libreadline.so.8 /usr/local/lib/libreadline.so.7

When the payload generated by rVIPER Wearg/ServersLog.tcl has been tested with Postman, it works fine.

Actually, for a server point of view, certificates are located in /usr/share/openfire/resources/security.

Helped on IRC, works fine now. :)

Hi Mr. Dereckson,

(currently, the port doesn't answer anymore, you perhaps closed the old egg instance?)

Yes, there is already an eggdrop listening on this port:

It seems another process uses the port 2003.

For reference, upstream Docker image uses the following PHP configuration: