The Ultimate BSD Thread™ - The Devil Wears a Neckbeard

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Ultimate BSD Thread™ - The Devil Wears a Neckbeard

evol262: Nov 30, 2010; #!/usr/bin/perl

Ninja Rope posted:

Yes, but my point is that those companies aren't just downloading 10-BETA2 and putting it on production servers and calling it a day. They have FreeBSD committers on staff to work cherry-pick patches and test only specific configs, as well as fix bugs as they occur (and feed them back upstream). I didn't understand the question to be "is FreeBSD suitable for production", which in a general sense it is, but "is the latest FreeBSD 10 beta suitable for a random internet user to use in production", which I think the answer is no. It will be, but it's not right now.

To be honest, this workflow is just as applicable to Linux. The people who are doing serious performance work find odd bugs, fix or report them upstream, and cherry pick patches to backport onto older kernels (especially for large clusters). Nothing about this is unique to BSD, and I'd be just as comfortable running 10-BETA or Debian unstable or Fedora 19 for an nginx+Sinatra+passenger or postgres. You run RHEL or SLES for stable ABIs for enterprise software which needs them (Clearcase, OracleDB, whatever), and APIs to a lesser degree (though BSD is much better about this), not necessarily performance or stability under load.

# ¿ Nov 7, 2013 04:56

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 22:29

evol262: Nov 30, 2010; #!/usr/bin/perl

lostleaf posted:

Did anyone else have problems with freebsd-update? I'm upgrading from 9.1-release to 10.0-release and it keeps on reporting integrity check fail. A quick google search tells me that I have to upgrade to the latest 9.x release then upgrade from that to 10.0. Is it really supposed to be that draconian?

Yes, it is.

# ¿ Jan 21, 2014 16:36

evol262: Nov 30, 2010; #!/usr/bin/perl

Riso posted:

As a client, doesn't it just pretend to be a NT4?

It's the opposite, really. As a server, it pretends to be an NT4-style domain (except for Samba4, which peers with 2012R2). winbind will happily talk Kerberos.

# ¿ Feb 10, 2014 22:33

evol262: Nov 30, 2010; #!/usr/bin/perl

roadhead posted:

Messing around upgrading some ports, mostly using 'portupgrade -a' and now I get this

code:

% SABnzbd.py
Traceback (most recent call last):
  File "/usr/local/bin/SABnzbd.py", line 53, in <module>
    from cherrypy import _cpwsgi_server
  File "/usr/local/share/sabnzbdplus/cherrypy/_cpwsgi_server.py", line 6, in <module>
    from cherrypy import wsgiserver
  File "/usr/local/share/sabnzbdplus/cherrypy/wsgiserver/__init__.py", line 105, in <module>
    from OpenSSL import SSL
  File "/usr/local/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import rand, crypto, SSL
  File "/usr/local/lib/python2.7/site-packages/OpenSSL/rand.py", line 11, in <module>
    from OpenSSL._util import (
  File "/usr/local/lib/python2.7/site-packages/OpenSSL/_util.py", line 4, in <module>
    binding = Binding()
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 83, in __init__
    self._ensure_ffi_initialized()
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 99, in _ensure_ffi_initialized
    libraries)
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/utils.py", line 72, in build_ffi
    ext_package="cryptography",
  File "/usr/local/lib/python2.7/site-packages/cffi/api.py", line 341, in verify
    lib = self.verifier.load_library()
  File "/usr/local/lib/python2.7/site-packages/cffi/verifier.py", line 73, in load_library
    self._write_source()
  File "/usr/local/lib/python2.7/site-packages/cffi/verifier.py", line 125, in _write_source
    file = open(self.sourcefilename, 'w')
IOError: [Errno 2] No such file or directory: '/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/__pycache__/_cffi__x5eaa210axf0ae7e21.c'

when I try and run SABnzbd - if I just run python and do the same import SABnzbd.py does it doesn't give an error? What did I break?

Because "import SABnzbd" won't call __main__.

Try reinstalling cffi

# ¿ Apr 15, 2014 17:58

evol262: Nov 30, 2010; #!/usr/bin/perl

roadhead posted:

I reinstalled that port already.

What this backtrace is telling is:

sab is trying to start cherrypy.
Cherrypy is using openssl through pycrypto
pycrypto is using terrible/dangerous bindings.
Those bindings are calling out to a native C library.

You have a few possibilities:

cffi is broken, but you updated it.
openssl was updated by pycrypto was not
pycrypto was updated by openssl was not

Other than cffi, it's likely that you got the heartbleed fix, and security/py-pycrypto needs to be rebuilt against the new library version.

# ¿ Apr 15, 2014 18:29

evol262: Nov 30, 2010; #!/usr/bin/perl

roadhead posted:

Ok I did a "make reinstall clean" for py-pycrypto and openssl and still no go. Is there something else I should try besides that command?

What are the versions of cffi and pycrypto?

# ¿ Apr 15, 2014 22:16

evol262: Nov 30, 2010; #!/usr/bin/perl

roadhead posted:

py27-cffi-0.8.2
py27-pycrypto-2.6.1

I've even backed up my sabnzbd.ini and did a "make reinstall clean" of it as well to no effect.

You'll probably have to ask the cffi port maintainer.

# ¿ Apr 15, 2014 23:20

evol262: Nov 30, 2010; #!/usr/bin/perl

Ninja Rope posted:

Unrelated, but what is a better python openssl API wrapper to use/why is that terrible?

Essentially, see this. There's nothing inherently wrong with it if you need to access OpenSSL or CommonCrypto primitives directly, but it's potentially dangerous. This is broadly true of everything involving SSL, though, and there's not really a better wrapper. They're all equally bad.

# ¿ Apr 16, 2014 19:35

evol262: Nov 30, 2010; #!/usr/bin/perl

thebigcow posted:

^^ Wouldn't NFS be easier between BSD and OSX? Or are they not quite compatible and require a bunch of work?

I like FileZilla on Windows for sftp, it even uses your key agent. I don't know how good the OSX version is though.

NFS is just terrible on OSX.

# ¿ Jun 6, 2014 20:12

evol262: Nov 30, 2010; #!/usr/bin/perl

sarehu posted:

Last time I tried that (shortly after 9.1(?) was released) it didn't work, there were no ports available.

If you didn't install the ports tree and didn't sync it, that would be true. Otherwise, it's just a directory tree with files that are pretty easy to look at.

sarehu posted:

No packages available to install matching 'emacs' have been found in the repositories.

This is true for any package other than 'pkg'.

Please look at the confs in /etc/pkg/ and /usr/local/etc/pkg.conf

It sounds like your repository config is broken.

# ¿ Nov 24, 2014 06:20

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

OK, so I posted a while back about my problems with PCBSD: Namely, I couldn't get the Nvidia driver working at all, and hence run Gnome-Shell.

I tried starting from scratch this week with the stock FreeBSD 10.1 installer.

I followed guides at [url=https://cooltrainer.org/a-freebsd-desktop-howto/]cooltrainer.org[/] & [url=http://www.bsdnow.tv/tutorials/the-desktop]bsdnow.tv[/].

As yet, no luck getting a Gnome-Shell desktop working, though I do at least have proper vt console and can startx and see the default xorg desktop.

I've probably made an error in manually typing one of the many config options in those guides, which I'll look at again tonight.

Two related problems I've found so far:

1)
Both these guides are actually suggesting to use ports exclusively, in part because the pkgng builds don't include compile time options for e.g. Mplayer and VLC that enable useful codec support.
It's not clear what use either of those players is without codecs, so this seems a poor choice to make the default.

Outside of those two examples, I can't think of any reason why I need to compile anything custom, but... Is there a way to avoid having to use ports for this stuff?

I'm used to the Debian method of just putting the whole binary in a separate "non-free" repository if freeness is a problem, and it will take some getting used to the BSD method.

2)
I pre-emptively typed pkg install <list of packages I use> at some point after the installer was finished.

When later following the guide and compiling various ports, I get errors and process quits due to the fact that I've already got the pkgng binary versions of some of the dependencies installed (I think).

gettext*something* library was one of the problem dependencies.

Any way to avoid this conflict?
Can I not safely mix binary packages and ports?

If not, is there a command to mass remove all the binary packages installed with pkg?

Just portmaster -a

I don't have any problems with vlc from pkgng, at least.

What's wrong with gnome-shell? Install it, enable hal and dbus, install nvidia-drivers and enable them in loader.conf, start gnome-shell

# ¿ Dec 5, 2014 15:29

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

Portmaster -a will remove all pkgng packages I have installed?

As far as Gnome goes, probably I missed or typoed something in the config, but my hardware is all unremarkable, not *too* new - Nvidia card is a 560 Ti.

Nether of those guides covered gnome-shell, but another I found told me to add:
code:
dbus_enable="YES"
hald_enable="YES"
gdm_enable="YES"
gnome_enable="YES"
to rc.conf

I'll check all these again, and loader.conf for
code:
nvidia_load="YES"
Also, I might've missed a package.

No. Portmaster -a will look for upgrades to installed packages, via ports.

Adding that to rc.conf should be fine. What's happening when you try to start gnome?

# ¿ Dec 5, 2014 16:54

evol262: Nov 30, 2010; #!/usr/bin/perl

Xenomorph posted:

Well, after wondering why my Logwatch settings never seemed to work right, I just found out the correct path for the configuration file on FreeBSD isn't mentioned anywhere.

Logwatch on FreeBSD uses /usr/local/etc/logwatch/logwatch.conf. I just tried a Google search for that;

The man pages and HOWTO say it uses /etc/logwatch. That directory is completely ignored by Logwatch on FreeBSD.

When you search for Logwatch "guides", all of them seem to tell you to modify /usr/local/etc/logwatch/defaults/logwatch.conf, which is a big no-no. That file is over-written with an update, anyway.

I had to look into the source of /usr/local/sbin/logwatch.pl to see where it was looking.

Am I missing something with this? Why cannot I find correct documentation for Logwatch on FreeBSD? Why would their own documentation on it be wrong? "man logwatch" seems to suggest that you use /etc/logwatch.
/usr/local/share/doc/logwatch/README and /usr/local/share/doc/logwatch/HOWTO-Customize-LogWatch both say to use "/etc/logwatch/conf/logwatch.conf"

I guess another bug report is on my ToDo list...

It's not a bug.

The docs may be a bug, because they seem to have just packaged the default documentation, but as a general rule: if the binary is in /usr/local (because you installed it from ports or packages), the config file is in /usr/local, as is the init script

# ¿ May 5, 2015 18:28

evol262: Nov 30, 2010; #!/usr/bin/perl

D. Ebdrup posted:

I've been playing around with bhyve a lot, but didn't know this. Since you posted, I've been playing around with it and it's actually really neat.

Tangentially related to the above image, I know FreeBSD gets used in core routers (JunOS), TVs (Panasonic), Playstation 3 and 4, the Mars rovers (specifically the FreeBSD netstack) and many other surprising places - along with some not-so-surprising like a lot of mail servers on the web - but I've never heard of any cars running it. It'd be kinda neat if it was used there as well.

The netstack gets used everywhere, but that's not a great indication of usage. Windows also used it for a long time. JunOS is also pulled from comparatively ancient versions of FreeBSD, even recent versions.

FreeBSD leaves a lot to be desired in realtime applications, but there's a realtime patchset and canbus drivers, so it's possible, but nobody's talking about it if so, without even getting into certifying it to work in given scenarios. QNX and VxWorks are still very much kings of that (embedded realtime OS) hill.

# ¿ Oct 8, 2015 19:35

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 22:29

evol262: Nov 30, 2010; #!/usr/bin/perl

If you want questionable advice, use launchd

# ¿ Apr 7, 2017 06:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Ultimate BSD Thread™ - The Devil Wears a Neckbeard