What's taking so long for FreeBSD 7 ?

With a bit of hoop jumping its quite possible to run DA on a server and manage just about everything with ports, the exception I've got at the moment is exim which I'm still running from the da_exim pkg, vm-pop3d isn't an issue we're using Dovecot and proftpd seems fine straight from ports. The biggest hoop was apache, but we compromised on /usr/local/etc/apache22 and its config then including the ips.conf and /etc/httpd/conf/httpd.conf just having the Include lines for the virtual hosts.

We've only done this on one server though, after that management opted for FedorianOSHat instead and someone else now gets to manage them, I handle our internal systems (FreeBSD) manually.

Only thing I'm now wondering is if a portupgrade update of perl to 5.8.9 is going to break Exim at all. It looks like /usr/sbin/exim is statically linked but I'm still a bit apprehensive.
 
Despite DA not using the ports system on FreeBSD I do get messages from portaudit, like

Affected package: proftpd-1.3.1
Type of problem: proftpd -- Long Command Processing Vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/0f51f2c9-8956-11dd-a6fe-0030843d3802.html>

Affected package: freetype2-2.3.5
Type of problem: FreeType 2 -- Multiple Vulnerabilities.
Reference: <http://www.FreeBSD.org/ports/portaudit/4fb43b2f-46a9-11dd-9d38-00163e000016.html>

Affected package: png-1.2.23_1
Type of problem: png -- unknown chunk processing uninitialized memory access.
Reference: <http://www.FreeBSD.org/ports/portaudit/57c705d6-12ae-11dd-bab7-0016179b2dd5.html>

So despite not being installed via the ports, they are registered? It's a bit odd to have portaudit report this and then not be able to update them via the ports, just in case something gets broken (compilation wise or config wise).
 
yeah i also had portupgrade report this ports...

guys also check after rebuilding the directadmin to not relink the libiconv.so to another libiconv, that can render your system useless by segfaulting csh.
check the link in /usr/local/lib/libiconv.so to lead to libiconv.so.3 not so.6 or anything that DA may provide...
 
This is a fairly large thread yet noone from DA has chimed in. Why is that? I'd like to hear from someone from DA on what they intend to do. Im still running 6.1 and 6.2 installs but im ready to start upgrading my boxes.
 
Hello,

We'll look at changing the iconv to use ports instead of from source in custombuild.. that's really the only hangup right now for it's "unstable" status. The workaround for using /bin/sh is simple enough to do which is probably why it's been put off, but it's just that, a workaround.

John
 
Hello,

We'll look at changing the iconv to use ports instead of from source in custombuild.. that's really the only hangup right now for it's "unstable" status. The workaround for using /bin/sh is simple enough to do which is probably why it's been put off, but it's just that, a workaround.

John
Maybe there's a way to edit a custom build script to use ports?
 
Got 2 DA boxes running FreeBSD 7.0, with the reminder ealier in the thread that 7.0 is indeed EOL I will shortly be updating these boxes to 7.1, I expect no problems since minor freebsd revisions tend to not break things like directadmin.

The problem I see at the moment with the freebsd support is the obvious lack of port usage, the broken csh binary after installing DA and that it installs out of date packages.

Utilising the ports system would mean providing the ports tree is up to date then any installed packages would also be up to date, it would solve dependency issues hence the broken csh and it should in theory be easier for DA to maintain scripts as using ports is simpler than manual configuring/compiling.
 
With portsnap updating the ports tree has never been easier. They should definitenly use the ports. I don't think any FreeBSDer even questions that. I even think if they did take the time they might gain many more DA users in the BSD community that scoff at DA's lack of ports use. It's a weird akward feeling to install stuff in BSD without ports.
 
Could you clarify then if any of the steps (1, 2, or 5) from this post are required then to get FreeBSD 7.1 64 to work "out of the box" with DA?

http://www.directadmin.com/forum/showthread.php?t=27741&highlight=freebsd



I went through the above process this week to get one machine running. No real major issues but definitely not as easy as when running setup just works.

It is definitely nice to be able to get the full power out of the machines.

64 bit with 4GB RAM, DA, Freebsd 7.1

Processor Name Intel(R) Xeon(R) CPU 3065 @ 2.33GHz (2333.51-MHz K8-class CPU)
Total Memory 4082.01 MB
Free Memory 3387.13 MB

Same exact machine with 32 bit

Processor Name Intel(R) Xeon(R) CPU 3065 @ 2.33GHz (2333.51-MHz 686-class CPU)
Total Memory 3314.17 MB
Free Memory 1952.39 MB


Thank you for continuing to support FreeBSD. I would also like it if everything used ports but I have no problem settling for just working without having to do a ton of custom changes and tweaks each time I need to set up a new server or update an old one.
 
all 3 steps will be needed, especially step 1 else you risk locking yourself out of ssh after sshd is restarted.
 
Back
Top