Messages

#1 First thing I would do is eliminate the WiFi router between your OPNsense and your modem. OPNsense can handle modems (and VPN), quite well too - and: OPNsense is by fare the more capable firewall than your WiFi plastic box!

=>Why you set your network up in this way? Is the WiFi router in one box with the modem or are they separate boxes? If there are no specific reasons for this setup of yours - eliminate it , please.

#2 O.K. now:
What to do with the WiFi router afterwards? -> Take 1 (bridged) LAN port unbridge it and make it take a separate Network IP address, match the already established IP network of your WiFi plastic box, this is sometimes called a DMZ.

=>This alone would eliminate some error cases, because we would deal with pfSense configurations alone. In anotherv words it would help us help you!

Sincerely chol.

P.S.:
May I ask why you chose such a 'speaking' alias name "pigbait"?

[ACK]

Thank you, Franco, you have presented very reasonable suggestions and your questions are very thoughtful.

Let me react:

*PRO:

Some have said the version is too long. To leave any taste out of this, let's just say the version string is long. We are aware. ;)

I agree, for the name-strings are not recognizable on the download pages any more, because they are displayed shortened, leaving a redundant list of OPNsense_OpenSSL_..... one under another. The crucial things to differentiate, like platform(i386,amd64), target (vga,nano,serial) should be shown first, in other words, I would opt for a reverse naming convention of our current "name-strings", if they have to stay long.

o 16.1 and 15.7 series will part ways very early on, with 16.1 receiving larger batches of changes and 15.7 receiving only bugfixes.
(..)
o Merging the minor version and bugfix version, so that version strings will never extend beyond 15.1.x. It would make certain jumps look larger or smaller, but maybe it doesn't matter in the grand scheme of things with a good firmware update procedure in place like we have.

Full ACK! That is what I really look forward to see.


*UNSURE:

o The frequency of ports updates could be increased to daily snapshot mode that may come without an associated OPNsense version bump when triggering an update (this is more in the likes of FreeBSD)

Does this imply full port updates or just security updates/fixes in relation to our ports? Could this be labeled "stable" in any association? If not I highly recommend the option for the user, to stay kernel and ports conservative and only security fixes daily (default) or to override this and stay hot-edge for the user's appliance!

o The target frequency for updates was every week and that worked out ok, except when there was nothing to release or two releases happened in the same week. Was this enough, or too much? Should it be faster? There are ups and down to all of the possibilities.

In my oppinion it is o.k. becuase we have an early OPNsense development! But for the future, I would look on this from the perspective of needed * reboots *. Taking the versed user into account, the reboots should be limited - and never come close to a weekly, or even more frequent habit. You may implement a transparent automated or mediated remote update feature (for the family/living community/club with 2 or more OPNsense appliances and just one 'IT guy', or the SOHO business/office  (payed for, remote from netherlands or whatever, as a service).

=* inflexible Automated (standardized) vs flexible User triggered (highly customized) Update-Paths*=
Maybe security updates and upgrades should by default be applied transparent and automatically from our OPNsense servers - even across major FREEBSD versions (-10.1 11.0) if this would be possible.

Moreover for advanced security, we should have a kind of port-pattern cloaking-schematic: by means of random ports for services (documented on console and logs/GUI) or port knocking - to make the surely growing numbers of OPNsense appliances not recognizable by automated cracker's port sweeps.

Remember: nothing is set in stone. :)

For me this is (another) proof of the OPNsense way, and this is our motto: "Open (source) makes Sense"


*SUGGESTIONS:

(..) we were thinking about the version number system we have come up with over the course the past 5 months and what to do with them after 15.7 comes out.

This comes with a tail: the names and directories of download servers may also have to be planned, as we seem to progress into a more stable 15.7, a development 16.1 and also have experimental versions, e.g. LibreSSL (as of now, this might change/merge I am aware) and HardenedBSD images. This needs to have thoughtful structure, which would not change all too often, too.  I noticed updates to the OPNsense.org download site, with 2 notable things: the mirrors are up-to-date, that is nice, and the sourceforge download-link is missing, why - surely there are reasons for this?! Will the server location(s) and its structure of diverse downloadable versions need help from an additional person (now, in the future) that will take care?

"15.1" describes the major with year (two digits) and month of the release. Our releases are planned for January (1) and July (7), but they may shift as we go into 2016.

Please, let's have an announcement protocol for this, too, not just for the downloadable images, you developers are mostly concerned with. For me, it would be nice to have infos in advance and not find out and reverse docomentation I have just edited and researched, but were out-dated behind the scenes, already. This is frustrating. If this means more work, by all means I would not like to load it on other shoulders but would offer help on this, too, but it should have an agreed uppon structure, better a "protocol" (like etiquette) , that would make cooperation besides developer meetings and "hollandian round tables" (  I really mean it nicely, guys - just to clarify my point ). But obviously these are just my opinion and may not be practical.

15.7 will likely based off of 10.1-RELENG as well. What this means is that after 15.7 is out it'll stay on 10.1-RELENG, maybe getting bumped to 10.2-RELENG when released, while switching 16.1 to 10-STABLE, most likely based on HardenedBSD.

???
Now, what does -RELENG stands for?
-STABLE is a current Snapshot cutting edge.
-RELEASE is a stable distribution.

But RELENG never came across this. I am just curious.

The new implemented upgrade functionality is a fine piece of software, clear, straight forward, guiding, informing, in a word a *satisfying experience*

Thanks to Jos, Ad & Franco

[no]

*Keep Calm and let's enhance security together!*

CMB (like Chris M. Buechler?), if you feel the need to explain your motives and project aims further, or to drew on facts that might seem to be vulnerable for misinterpretation, please give us your insights!!

Your insights are highly valued here, I promise.
Why? Because it is a fork based relationship only, with mutual interests and probably competing goals divided by a huge ocean (EU vs US).
There should be ways to cooperate more friendly.

Dear CMB, please take into account, that OPNsense and pfSense share the same cultural and ethical background, what would probably differ horrendously, if the -lets say- North-Koreans, or IS  would take the step to fork your highly valued pfSense code (or ours).

about "licensing issues", Franco? All our code is under the same license today as the code you forked.

That's def. good for your *pfSense* code  :)

If there were "licensing issues" to pulling it in (which there aren't), then your entire code base would have same "issues."

The OPNsense project entirely runs under a different license than the ESF-license for pfSense. It is shorter and clearer, one does not need a lawyer to explain it, classical.

lying about "licensing issues"

As a matter of fact there is no lie involved in Francos message!

In my understanding, in comparison to the simple 2-clause OPNsense license, dealing with the ESF-license, inheriting 7 main terms and many sub-terms and sub-conditions more, in general  bears issues for us (not four you). Franco surely alluded to that fact! 

The "ESF License Agreement, v1" has these terms and conditions, as anyone can see:

*1a - f     (6)
*2a - b    (2)
*3a - g    (7)
*4           (1)
*5           (1)
*6a - b    (2)
*7a - e    (5)
-----------------
total       (24), I am sure professional lawyers would find many (implicit) more ...

Many of us here are pfSensae users, bought your books, used pfSense for years, recommended it for buisinesses and private use cases and promoted it as a fine example of software out of the BSD realm...

Our intent here is not to lie about you, CMB, or *your* pfSense nor your code nor your license.

In a word we like you and your project -  as an offspring of yours - only we confident and happy stroll a different path, now... :)

See also:

* pfSense - Yes, everyone who wasn't an actual ESF employee got locked out of '-tools'.

[*** Welcome to OPNsense 15.1.11.3-d007whatever (amd64) on OPNsense ***]

O.k. Thank you for the help.
I did not anticipate it could be a trashed pkg - so you may understand my initial question about differences and possible changes in repository and image, neighter did I see the _1 in the kernel namestring before, sorry for that.

running

# /usr/sbin/pkg

or

# /usr/local/sbin/pkg

gives error: "runtime library has no shared object"

# portsnap fetch

says "command not found"

---

SOLVED:

#cd /usr/sbin

# fetch http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/pkg-1.5.3.txz

#tar -C / -xvzf  pkg-1.5.3.txz

# exit

Console menu item 12) Upgrade from console runs seamlessly now!!

*** Welcome to OPNsense 15.1.11.3-d007whatever (amd64) on OPNsense ***

Thank you!!  :)

chol..

Hmm, can you do a quick:

# ldd /usr/sbin/pkg
# ldd /usr/local/sbin/pkg

# ldd /usr/sbin/pkg

Gives a list of 14 libraries (lib[..].so.#) with a => director to their positions in the root tree, each with a hex (0x80[..]) numberal

# ldd /usr/local/sbin/pkg

gives nothing

Found this:

* similar bug:
https://forums.freebsd.org/threads/bin-sh-shared-object-has-no-run-time-symbol-table.43007/

* might be a disc error, says:
https://forums.freebsd.org/threads/error-when-starting-sshd.36657/

* "Shared object has no run-time symbol table" usually means FreeBSD can't
find a library file you linked the code against, says :
http://lists.grdata.com/pipermail/rtg/2004-December/001375.html


Seems to be a corrupted pkg or a corrupted library file..

[default kernel]

O.k.

From the console menu item 8 Shell =>

# opnsense-update -kr 15.1.11

did the trick and fetched and applied the 15.1.11 kernel.

* A reboot of the default kernel from the bootup menu delivered the 15.1.9 kernel and #pkg upgrade failed:

/usr/local/sbin/pkg: Shared object has no run-time symbol table

* A reboot of the old kernel from the bootup menu

delivers the same .. ??

[grade]

"grade" seems to imply level up or down (grade A is higher than grade B, etc..)

"date" seems to imply fetching the newest stuff but not necessarily leveling up/down

In your version naming logic, is

.. going from 15.1.9 to 15.1.11 an upgrade or an update?

And from 15.1.11 to 15.1.11.3 would be called what, update ?

And from 15.1.x to 15.7 would be  -at least- called an upgrade?

What is your version naming logic, and does it reflect in names/functionalities of tools/script sets? What would you say (that is the important say, not mine)?

---

Another ERROR:

O.k. I did start my LibreSSL 15.1.9 install from two days ago. This on real hardware, an old Intel Atom box.

And tried to use console menu option 12) Upgrade from console, like I did just minutes ago with my VirtualBox VM quick install of LibreSSL

got the error :

/usr/local/sbin/pkg: Shared object has no run-time symbol table


Shell =>

# opnsense-update
Fetching kernel-15.1.9-amd64.txz ... fetch: http://pkg.opnsense.org/sets/kernel-15.1.9-amd64.txz: Not Found


Seems to be a different behaviour:

The VM install tries to querry a "OPNsense reporitory catalogue" first. Did you change the update tools?

[1.9]

Franco, out of your perspective, would you say?

Going from 15.1.9 to 15.1.11 would be an upgrade or an update?

And from 15.1.11 to 15.1.11.3 would be called what, update ?

And from 15.1.x to 15.7 would be  -at least- called an upgrade?

The OPNsense_OpenSSL_15.1.11.3 install shows:


# pkg info | grep -i openssl
openssl-1.0.1_19

and

# pkg info | grep -i libre

shows nothing.

So I have two installs with each having libressl OR openssl !!

O.K. I know more now, thank you again, Franco  :)

The console command

# pkg info | grep -i libre

gets me

"libressl-2.1.6_1"

---

# pkg info | grep -i openssl

gets me

"php56-openssl"

.. so it seems both are installed, and in the future one would have the OPNsense GUI option to change the SSL library used?

O.k. the 3rd install delivers exactly what I got 10 days ago: Console menu item 12) Upgrade from console got me a LibreSSL 15.1.11.3 system. Eventually!

Look up the new  screenshots please.

Thank you for the repo fix.

Any idea how to debug your not being able to upgrade the old LibreSSL snapshots?

O.K.:

For the quick approach I did an other install of the same OPNsens_15.1.9_1-LibreSSL-amd64 image from two days ago into a virtual machine (Vbox)

Look the screenshots with error messages, please.

P.S.

the upgrade from console got me the 15.1.9 LibreSSL

and

% opnsense-update -kr 15.1.11_backports && reboot  failed

% pkg upgrade -y

got an error "writesystem is full"


VM has 1GB RAM , 2GB HDD