Messages

I am testing this since yesterday having a couple of issues that I haven't been able to locate. The bridge setup isn't as clear as it should especially WRT the bridge being hooked into an existing interfaces as opposed to moving the existing interface config to the bridge. I'll look into this more in the next few days. Thank you for the report. :)

I'm assuming WAN count "1" works, but "2" doesn't. The code checks which interfaces have gateways (IPv4 or v6) or is of the following type: dhcp, pppoe, pptp, l2tp, ppp, ovpn, gif, gre.

Maybe your setup changed? Maybe an interface setting got lost? We haven't touched the wizard in the last 3 months. Any help to debug this is appreciated. :)

Don't know about the interface setup, but I want to reply to Pulsar:

That's true for larger deployments, but smaller users or business owners tend to approach everything with a one-size-fits-all solution. That's why we have UTM in the first place. Too much demand not to address it.

I am beginning to understand why this is important.... It's a static WAN setup (or no DNS via DHCP) and pkg.opnsense.org needs to be resolved in order to upgrade. We could try to ship with a standard DNS server for such cases, but, OTOH that isn't really good as it would "leak" your queries to the internet by default (most don't care but it makes sense to to assume that's not in the best interest of privacy).

How did you configure the setup? Any particular console menu item? Maybe it's worth asking the user if he wants to enter a DNS server while configuring WAN port?

Thanks for the productive discussion. :)

Thanks for taking the time to research this. Crash reporter send will be back shortly. In the meantime a copy+paste for non-core dumps is okay anywhere: email, forum, twitter. :)


Cheers,
Franco

Watching yall' commit in the last month, I realized that I may be a bit premature submitting changes- since yall' are deleting/reworking bits, it'd be a shame for me to waste time cleaning up lines of code which will disappear.

Please keep doing that. I realise there is much to clean up but having more patches maybe makes us more aware of problems or stale code than without reviewing said patches. I'll do my best to merge pull requests manually and selectively no matter how far the code base has progressed.

I'm not sure I know/understand that trick, what is it?  If it makes it easier to read or parse, I'm all for it.  I'd love to one day see something with less GNU take the place of gettext, but I'm totally not thinking about that right now.

I think wordpress uses "__()" for all translations and redefines it to gettext(). gettext() itself defines _() so even though it's shorter if gettext() goes away we have to replace _() too or maybe do compat glue that potentially breaks while syncing the PHP shared objects like gettext or a sensible replacement. "__()" we can define via PHP and move to any function we want. That is e.g. great for trying replacements from a dev perspective without breaking the code or ugly hacks as only the call inside __() needs to be adjusted leaving the rest of the code as is.

Certainly- I'm no I18N expert, but I think basic coding policies are always good.  But some of the trouble cases are so obvious, they merely require sane eyes to clean up.  For example, here's a fun one:

Code Select Expand

core:src/www/interfaces.php:2150

Frankly, as much as this line is freaky- with the age and number of hands that have been on this code- I'm surprised at it's quality.  I've unfortunately seen much much worse, professionally speaking.

I looked at   and thought well, that's not so bad--not realising the string spans multiple lines including HTML. :D

I think you are right. The translations have been maintained with fair quality as it stood the test of time (and the Portuguese is really good and thorough as far as I remember).

Sweet!
In the future, so you don't feel burdened- I (and I hope others), will certainly help to keep things up to date too.
I'm mostly focused on keeping track of Japanese as time moves on, but keeping track of the English file is of course fundamental to that effort.

I understand. We constantly fiddle with the wording and clarity of the text and it makes a lot of sense to take care of the English translation file directly and steadily. I'm all for small incremental changes as opposed to large drop ins that put the workload on the other translations (e.g. right before a release; makes no sense at all).


Cheers,
Franco

Hi Isaac,

- The branch I'm working from is now 28 days old, and I'll need to check the diff for any relevant changes to the translation file.
(Incedentally, I found a number of odd gettext calls in the source which I'll address later)

I read about those in your commits. The gettext() usage is quite bizarre at times. If you can point me to the lines or add pull requests for those that'd be lovely.

Speaking of gettext, I was thinking we should maybe consider doing the "__()" trick consistently. For one "_()" is just easier on the eyes and the double underscore makes it possible to replace the translation function if we ever decide to switch to non-gettext variants. What do you think?

- After a lot of slogging through the source code, I could generate much of the English .pot file content in an automated manner.  Yet, as with problems like this, comprehensive parsers take far longer to write than just editing the file- there are so many edge cases for how the strings are handled in the codebase.

I'm all for ditching edge cases. Maybe we also need guidelines on what is translated and how dynamic strings and html are embedded (or not). A wiki page or README on this would certainly help to keep the English translations high in quality. I'm not a professional in that regard as well, so I believe that would be a chance to improve and share knowledge.

Expected outcome: when I'm done with this pass, a functional .en POT file will be ready to push upstream, and I'll submit a pull request as soon as that's ready.  Yet, there will be a few things still to do from there:

Looking forward to it. :)

- OPNsense core will want to maintain the English file, as the canonical base for all other languages
- The gettext machinery will need to be hooked up in to make it all work

Agreed, we can definitely do that.


Cheers,
Franco

I'm curious why you need the DNS servers in the first place. The GUI is reachable via the IP after setup, where the DNS servers can be configured. Are you trying to mimic a unattended installation or a headless deployment?

This is what we would think is part of our API work so that we can have a remote client or command line utility to serve this purpose. Not sure if it's worth writing a local console utility to rewrite DNS servers, but I'm not against merging the code if it's there. :)

cpdup(1) may be allocating too much RAM or it is part of the new async write we have pushed into the BSD installer. None of those issues are unsolvable, even though they shouldn't materialise in this out of memory kill sort of way. We'll find out why, no worries. :)

Demetris,

The FreeBSD ports tree still isn't ready by default (Python 2.7 is missing LibreSSL build support). I have some patches to push upstream as well, and Bernard and others are doing a lot more work behind the scenes. See:

http://www.bsdnow.tv/episodes/2015_03_25-ssl_in_the_wild (the interview bits with Bernard Spil)

There is the question of hardware acceleration which isn't in LibreSSL as far as I heard, but I need to check back with LibreSSL devs to be sure or hear their plans.

What we are most likely going to do is release both versions officially in the future as soon as we have automated build infrastructure up and running (building 2 versions in parallel was tricky, building 4 is impossible from this laptop). Donations and help are welcome in that regard. This will most likely materialise for 15.7.

In any case, LibreSSL builds are becoming more frequent with images and timely updates and we want to keep this up. :)

Bump your VM memory to 1 GB and it will install fine. In the meantime I'll try to find out more about why that is. It shouldn't hog so much memory.

No need, this is expected. We've had stability issues with the GUI in the past versions and are about to hook in the base updates as well as we grow confident the GUI won't glitch out, trashing boxes in the process. Thanks for the clarification.

Maybe it was the GUI update which does not update from FreeBSD 10.1-p8 to FreeBSD 10.1-p9on purpose as describe in the patch notes (the recommended method is the console firmware upgrade). p8 has the crash, p9 doesn't.

cdrom? amd64? i386?

I cannot help without knowing more details. The virtual box settings are ok. I test all images for a working install. I am not sure why this happens for you.

The next version will have support for filtering via OpenDNS.

https://twitter.com/opnsense/status/586820576343363584
https://github.com/opnsense/core/commit/884fac34e50f799b357e3469868285de92e2d878