always remember to do the following after upgrading PHP, but before restarting apache:
1 2 | cd /usr/ports/www/suphp make deinstall && make reinstall |
when using eaccelerator do:
1 2 | cd /usr/ports/www/eaccelerator make deinstall && make reinstall |
too.
Saves you a LOT of headaches 
The FreeBSD developers are clearly stepping up the pace with the second RC for 7.1 out in almost no time after the first one hit.
What’s next guys? -RELEASE before new years?
One day, you’re bouncing all over the place because there’s an official 7.1-RC1, the next, there’s already two security advisories.
To sum them up:
Index: sys/kern/uipc_domain.c =================================================================== --- sys/kern/uipc_domain.c (revision 186366) +++ sys/kern/uipc_domain.c (working copy) @@ -112,13 +112,18 @@ #define DEFAULT(foo, bar) if ((foo) == NULL) (foo) = (bar) DEFAULT(pu->pru_accept, pru_accept_notsupp); + DEFAULT(pu->pru_bind, pru_bind_notsupp); DEFAULT(pu->pru_connect, pru_connect_notsupp); DEFAULT(pu->pru_connect2, pru_connect2_notsupp); DEFAULT(pu->pru_control, pru_control_notsupp); + DEFAULT(pu->pru_disconnect, pru_disconnect_notsupp); DEFAULT(pu->pru_listen, pru_listen_notsupp); + DEFAULT(pu->pru_peeraddr, pru_peeraddr_notsupp); DEFAULT(pu->pru_rcvd, pru_rcvd_notsupp); DEFAULT(pu->pru_rcvoob, pru_rcvoob_notsupp); DEFAULT(pu->pru_sense, pru_sense_null); + DEFAULT(pu->pru_shutdown, pru_shutdown_notsupp); + DEFAULT(pu->pru_sockaddr, pru_sockaddr_notsupp); DEFAULT(pu->pru_sosend, sosend_generic); DEFAULT(pu->pru_soreceive, soreceive_generic); DEFAULT(pu->pru_sopoll, sopoll_generic);
Index: libexec/ftpd/ftpcmd.y =================================================================== --- libexec/ftpd/ftpcmd.y (revision 185134) +++ libexec/ftpd/ftpcmd.y (working copy) @@ -1191,7 +1191,7 @@ /* * getline - a hacked up version of fgets to ignore TELNET escape codes. */ -char * +int getline(char *s, int n, FILE *iop) { int c; @@ -1207,7 +1207,7 @@ if (ftpdebug) syslog(LOG_DEBUG, "command: %s", s); tmpline[0] = '\0'; - return(s); + return(0); } if (c == 0) tmpline[0] = '\0'; @@ -1244,13 +1244,24 @@ } } *cs++ = c; - if (--n <= 0 || c == '\n') + if (--n <= 0) { + /* + * If command doesn't fit into buffer, discard the + * rest of the command and indicate truncation. + * This prevents the command to be split up into + * multiple commands. + */ + while (c != '\n' && (c = getc(iop)) != EOF) + ; + return (-2); + } + if (c == '\n') break; } got_eof: sigprocmask(SIG_SETMASK, &osset, NULL); if (c == EOF && cs == s) - return (NULL); + return (-1); *cs++ = '\0'; if (ftpdebug) { if (!guest && strncasecmp("pass ", s, 5) == 0) { @@ -1270,7 +1281,7 @@ syslog(LOG_DEBUG, "command: %.*s", len, s); } } - return (s); + return (0); } static void @@ -1300,9 +1311,14 @@ case CMD: (void) signal(SIGALRM, toolong); (void) alarm(timeout); - if (getline(cbuf, sizeof(cbuf)-1, stdin) == NULL) { + n = getline(cbuf, sizeof(cbuf)-1, stdin); + if (n == -1) { reply(221, "You could at least say goodbye."); dologout(0); + } else if (n == -2) { + reply(500, "Command too long."); + (void) alarm(0); + continue; } (void) alarm(0); #ifdef SETPROCTITLE Index: libexec/ftpd/extern.h =================================================================== --- libexec/ftpd/extern.h (revision 185134) +++ libexec/ftpd/extern.h (working copy) @@ -46,7 +46,7 @@ void ftpd_logwtmp(char *, char *, struct sockaddr *addr); int ftpd_pclose(FILE *); FILE *ftpd_popen(char *, char *); -char *getline(char *, int, FILE *); +int getline(char *, int, FILE *); void lreply(int, const char *, ...) __printflike(2, 3); void makedir(char *); void nack(char *); Index: libexec/ftpd/ftpd.c =================================================================== --- libexec/ftpd/ftpd.c (revision 185134) +++ libexec/ftpd/ftpd.c (working copy) @@ -2794,15 +2794,20 @@ myoob(void) { char *cp; + int ret; if (!transflag) { syslog(LOG_ERR, "Internal: myoob() while no transfer"); return (0); } cp = tmpline; - if (getline(cp, 7, stdin) == NULL) { + ret = getline(cp, 7, stdin); + if (ret == -1) { reply(221, "You could at least say goodbye."); dologout(0); + } else if (ret == -2) { + /* Ignore truncated command. */ + return (0); } upper(cp); if (strcmp(cp, "ABOR\r\n") == 0) {
I noticed that the -RC2 branch is in place too now. Almost there…. must … be … patient …
You got to love the way they write the release announcements:
“Gee. Did we really implement that new interface that way? That needs a bit more work.”
So, it’s now the last few legs of the release cycle, and I’m looking forward to it.
DO read the release announcement or /usr/src/UPDATING, specialy if you currently have a system that uses the em(4) driver (Intel E1000 NIC), it might change with this release, to igb(4).
We’re only a little bit removed from the next major FreeBSD release. The branch has been tagged, and the ports-tree is (thank God!) unfrozen once again. The first Release Candidate has hit the FTP servers.
I’ve been running -PRERELEASE for a while now, and haven’t found any problems so far, not on real-steal hardware, nor on vmware virtualized hardware.
Ivan Voras made a nice post called FreeBSD under VMWare, it has very usefull tips. Read more here.
it covers a number of common pitfalls related to using FreeBSD in a vmware setting:
if I come up with some more interesting things, I’ll post them here.
First of all: do not panic
Second: get some coffee
Finaly: rm /var/db/pkg/pkgdb.db
I think this comes from upgrading portupgrade somewhere along the line, and accidentaly switching between database formats (hash, or bdb4 btree). The strangest thing is that I’ve searched high and low with Google, but no results anywhere. (not even any of the FreeBSD maillinglists). So it took me a little while to figure out this one.
I like HP servers. True enough, I like Supermicro better, but big companies tend not to like Supermicro due to the fact you have to assemble them yourself, and there’s no real support / SLA agreement possible with them (for now – I hear it’s in the works). Most people in the ISP world know however, that Supermicro is extremely reliable stuff, and priced extremely nicely.
Anyhow, I’m stuck with HP, which is not a bad platform to get stuck with to begin with. FreeBSD runs beautifully on it, but then you have to do without the insight manager agents, the same deal applies when you run Ubuntu. Centos 4 and 5 are a breeze, just edit /etc/redhat-release so it reflects a RedHat version of Enterprise Server, and install the software like you normaly do.
One thing I seriously dislike however, is that when I run Ubuntu or FreeBSD on a HP box, my monitoring capabilities drop to almost zero. With RedHat or Centos I can monitor through the insight manager agents (who hook into SNMP), and use the nagios check_compaq_insight.pl, and as soon as something breaks: I get paged. With FreeBSD (and ubuntu) that seems completely impossible. My last attempt on an Ubuntu box to install those agents resulted in some very serious library problems, because the installer auto-installed some distro-specific rpm’s. That showed me who’s boss. (not!).
Anyhow, during my daily stroll at the Nagios Exchange I noticed a plugin that I hadn’t noticed before: check_ilo2_health. This is a great little plugin written in Perl. Instead of the old: talk to snmpd approach, this little bugger talks directly to the ilo2 interface (ilo/il01 won’t work), and more specifically: it’s XML interface.
wait. did you say XML interface?
Yup, the ILO2 sports a nice new XML interface, with which you can communicate. HP even provides a bunch of examples on how to talk shop with it. Nice hey?
Now I thought, did HP actually put everything you can monitor with the insight agents into the ILO2 and make it accessible with XML?
Unfortunatly: no. (yes, that was quite disappointing).
You can get quite a bit of useful information through the XML interface, including the speed of the fans, temperature readings from all the internal sensors. You can even configure a lot of things, like users and IP settings through it. You can even upgrade the ILO2 firmware through the XML interface. But nothing on RAID status, rebuild status, etc. I tried this against a brand spanking new DL380 G5, so if it doesn’t work there, it won’t work anywhere.
If anyone at HP reads this: please extend the ILO2 so everything is accessible through it’s XML interface. That saves us a lot of trouble of trying to get those agents installed on other operating systems. FreeBSD is too good an OS to ignore, even for an OEM as big as you. (and you don’t, judging from this news-snippet (PDF)). So either open up the XML interface more, or provide us with insight manager agents for FreeBSD. (I would be more then happy to help with testing).
Like I wrote earlier, I got a nice IBM eserver xseries 226.
After I figured out that the CPU was, in fact, 64-bit capable (amd64/intel64 – EM64T), I went and downloaded the x86_64 version of FreeBSD 6.2, burned it on CD, popped it into the drive, and….
nothing
Okay, nothing is an overstatement really, but as soon as it got to:
ips0: resetting adapter, this may take up to 5 minutes
The box completely froze, and nothing could persuade the thing to continue booting. (actually, even numlock didn’t work any more, which pretty much means that the box died trying.)
Now, no real harm done, the box isn’t production yet, and it has a good install in good old 32-bit mode, but I went ahead and e-mailed one of the developers for the ips driver (Scott Long), and told him about what I encountered. He confirmed that this was probably a 64-bit related bug, and would look into it. How is that for support?! (seriously, we are talking opensource, free of charge software here, and still I get a reply in a matter of a couple of hours! I don’t see certain commercial software houses doing that)
Anyhow, can’t wait to see what happens, because hey, what’s the use of having a perfectly good 64-bit cpu, if you are not going to use it to it’s full potential?
I recently got an IBM eserver xseries 226 from somebody, they only do HP in that shop, and it was a leftover from a takeover they did a little while back. Since he wasn’t going to use it, he gave it to me. Thanks a lot buddy! 
After some investigation, I found out it had the following specs:
Okay, since I wanted to install FreeBSD on it, I immediately downloaded 6.2, and installed it. But right after that, I was wondering, is this a XEON that does EM64T (or as intel likes to call it now: intel64)? It wasn’t easy to find out. IBM sells these boxes with both a normal 3.0 GHz and a 3.0GHz that does EM64T. Normaly, I would just check what FreeBSD writes in /var/run/dmesg.boot. It said the following:
CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU)
Origin = “GenuineIntel” Id = 0xf34 Stepping = 4 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x641d<SSE3,RSVD2,MON,DS_CPL,CNXT-ID,CX16,xTPR>
AMD Features=0×20000000<LM>
Logical CPUs per core: 2
Mmm, no sign of anything 64-bit there. But that line with AMD features did turn me a little suspicious.
A little asking around on #fifo didn’t yield any results either, but then I found a cute little tool called cpuid in /usr/ports/misc/cpuid. And guess what that one came up with:
Extended feature flags: 20000000:
EM64T Intel Extended Memory 64 Technology
So yay! I got myself a 64-bit capable XEON (now to reinstall the box with the amd64 version of FreeBSD).