Messages

Ich denke das ist ein GUI-Defekt oder einfach Faulheit beim Design. Um welches Feld auf welcher Seite genau handelt es sich?

Andreas, nur in aller Kürze, weil wie gesagt nicht die IPsec-Leuchte: Auf Englisch hast du denke ich mehr antworten. :)

Hi Frédéric,

That's a great idea! We can colour the icons directly:

o black: not configured/enabled
o green: enabled and working
o red: enabled and malfunctioning

It would also help getting rid of the spurious "services status page".

We're only about half-way through redesigning the menu, so any input is greatly appreciated. We have still time till 16.1 in January to make the menu even better. :)


Cheers,
Franco

You speak of automatically using their service to sign SSL certificates?

Someone was working on improving a daemon to do arbitrary (temporary) lockouts using https://github.com/opnsense/sshlockout_pf as the base. We use this utility to blacklist GUI and SSH access in case of bad logins and it's fully automated.

Hi John,

Isn't this a premium feature by some overly expensive companies, e.g. https://www.viprinet.com/ ?

Do you know of any open source that does this? I don't think so, but I can be wrong.


Cheers,
Franco

LAGG has some breakage history for both projects, we've amended a few things in the meantime, but I suspect this may be another one of those uncharted territory kind of bugs. No excuse here though, bugs need fixing.

Can you help describe this a bit more so we can make a proper problem report? What I need is a step by step guide to reliably reproduce the issue (setup guide).

Been rather busy with my new job but very glad to see you guys helping each other out. Makes me proud. Keep it up. :)

Hi Jakob, I'd go with the ISO and install. Another approach would be to have something similar to https://github.com/pfsense/pfsense/blob/master/tools/builder_common.sh#L799 to build a ready-to-go VM image.

Will this box run a stock FreeBSD 10.1? If so we can retrofit opnsense afterwards, skipping the boot problems I know FreeBSD has a better handle on. Should, however, FreeBSD 10.1 not work we are out of luck with this hardware.

Do not confuse the _dhcp and dhcp user/group. The former is used by the FreeBSD base system, the latter by the FreeBSD ports system.

Quick fix:

Running /usr/local/etc/rc.recover in a running system

Code story:

Nano has a twist in its setup that enables /var and /tmp MFS by default:

https://github.com/opnsense/tools/blob/master/build/nano.sh#L55

Since the FreeBSD package database resides under /var, nano invokes the following on bootup:

https://github.com/opnsense/core/blob/master/src/etc/rc#L126

Unfortunately, the original code added a regeneration step for the group and user files in case of disk crashes, and it does this recovery by default:

https://github.com/opnsense/core/blob/master/src/etc/rc.recover

This recovery step requires access to the package database, which is not there on early boot because there was no reverse symlink to /root/var/db/pkg, where /var/db/pkg really is:

https://github.com/opnsense/core/blob/master/src/etc/rc#L134

Code Explained:

Nano boots up for the first time and the recovery stage is ok creating the dhcp user/group, because /var/db/pkg is in the right place.

After bootup the package database is under /root/var/db/pkg with a symlink from /var/db/pkg so pkg doesn't have to be notified. Note that /var is a memory fs so that the symlink will disappear after reboot...

So after reboot recovery will kick in, but it can't find the database under /var/db/pkg because we moved it to persistent storage. The dhcp user/group is not found, causing problems later.

The fix is to also provide a link when /var is not mounted, which is persistent, but lies under the /var memory fs, see last github link.


I hope that explains it. :)

Hi Tom, it shows the process count in the system, it's about 160 for me, depending on which services/setup you run on the box. It has nothing to do with system load or cpu consumption. :)

Is the box still active? Have you tried to restore the box with the other box's config? Have you tried to swap place to see if the box or the network setup is the root cause? So many things to try. Alternatively, Deciso offers support if this is still of (business) interest.

Yes, for small money APU is the best.

Hi Tikimodel,

we usually wait for FreeBSD ports to cope, as of this writing, unbound is still at 1.5.5 for them. Should it not be updated in time for 15.7.18 next week we'll pick it up and try to get it upstream (but usually it won't be necessary given a few more days). :)


Cheers,
Franco