Tags: ports


  06:03:00 pm, by The Dreamer   , 976 words  
Categories: FreeBSD, CFEngine

Wonder if this will work - package_method=>freebsd_portmaster and /var/db/pkg

On my FreeBSD system, my apache webserver would get angry whenever I update the php & extensions ports. Requiring a bunch of other operations after the 'portmaster -a'.

Since I've been playing around with CFEngine 3, I had started to add to my "bundle agent apache", to do more than just promise config files current, process running, reloads, etc.

So, one of the first problems I had run into on FreeBSD, is that there are certain extensions that need to be in order in '/usr/local/etc/php/extension.ini'. Which is solved by using fixphpextorder.sh.

Well, fortunately when this script is run it results in a backup file of 'extensions.ini.old' which is the same age or newer than 'extennsions.ini'.

CFEngine3 can take care of it this way:


    "ext_dir"       string => "/usr/local/etc/php";
    "ext_file"      string => "extensions.ini";
    "fix_php_ext"   string => "/usr/local/etc/fixphpextorder.sh";
    "need_fix_php" expression => isnewerthan("$(ext_dir)/$(ext_file)","$(ext_dir)/$(ext_file).old");
        "$(fix_php_ext)"    contain => in_dir("$(ext_dir)");
        "$(g.lrc_d)/$(g.apache) graceful";

g.apache is "apache22" currently on FreeBSD, and "apache2" on Ubuntu. Someday it might become "apache24" on FreeBSD.

Since I did FreeBSD first, and I'm still working on getting my one of 4 (or less) Ubuntu rolled in, I have:

g.rc_d as "/etc/rc.d" and g.lrc_d as "/usr/local/etc/rc.d" for FreeBSD. They are both set to "/etc/init.d" for Ubuntu. I also have a g.init_d for Ubuntu, but not FreeBSD. Not sure which I'll use where....I suppose if its an OS specific case, g.init_d would get used and if its not...then which ever one is the correct one for FreeBSD will get used.

Pages: 1· 2


  05:58:00 pm, by The Dreamer   , 2452 words  
Categories: Software, Ubuntu, FreeBSD, CFEngine

Moving irssi

So, recently there was a 'long' 4th of July weekend....on account that I opted to take Friday (the 5th) off as well.

I kind of thought I would tackle a bunch of different projects this weekend, though I've pretty much shelved the idea of re-IP'ng my home network. Perhaps something to do when I get my configuration management better fleshed out.

What I decided was that it looks like its just one last thing on one of the two Ubuntu servers that I'm retiring. So, I figured I'd quickly move that and then go onto the next thing. In the end, I didn't get it completed until Monday night.

For background, some years back...after my return to IRC, I had initially gone with Chatzilla (being that Firefox was my standard browser), which later moved to xulrunner and Chatzilla so it was independent of my browser. Though it was kind of annoying having it running at work and at home, and somewhat confusing for co-workers that ran text based IRC clients in screen somewhere and ssh'd in, etc. Most people that did this, were doing irssi.

So, I initially built it from source and was running on my old RedHat 7.3 server, and that was usable. Later when I setup an Ubuntu box to replace that server (the hardware had previously been SuSE....acting as an internal router for ivs status tracking....) It evolved, in that I would start screen detached from rc.local....which was important since the system would see patches on a regular basis, requiring reboots....which is kind of a reason for switching to FreeBSD.

Over time, I would make little tweaks here and there, to this irssi setup. Like twirssi, doing ssl, and later bitlbee to integrate Facebook chat (came across some stuff that I should add now...)

And, incorporating other tweaks I come across online when there's some problem that becomes sufficient bothersome that I want to address. The one problem I haven't haven't been able to solve is keeping server/system messages confined to the one window. Namely keeping system CRAP going to the system window, and allow channel CRAP to show up in the channel windows....but instead I'll get system CRAP in whatever channel window is active. Which is annoying because its usually the work channel. Where it be just signal and no noise.


I had started to move things more than a month ago, in that I built irssi and bitlbee (including the cfengine3 promise for it...not really much config wise for cfengine to manage for irssi...though I envisioned promising that its running all the time, though irssi has generally been stable everywhere else that I've run it.

But, the I got distracted by other cfengine3 work. Even though things started to get pressing when twirssi stopped working, due to API 1.0 going away...so I had to update Net::Twitter and twirssi. Updating twirssi wasn't that hard to do, but Net::Twitter was a problem, so I opted to remove it and its dependencies and then installing it and its dependencies using CPAN.

I also made note to install net/p5-Net-Twitter from ports on dbox.

twirssi seems to be having other issues, which I had intended to investigate...perhaps after I move... But, that was like a month ago....

Full story »

Pages: 1· 2


  01:15:00 pm, by The Dreamer   , 694 words  
Categories: Software, FreeBSD, CFEngine

Meanwhile upgrading cfengine-3.4.4 to cfengine-3.5.0 not going well.

Upgrading the port was no problem....but it broke my cfengine. Why? The port puts the cfengine binaries in /usr/local/sbin, while the cfengine practice is that it has a private copy in /var/cfengine/bin. Which would be fine if the binaries didn't have shared library dependencies. Which they do, specifically libpromises.so.1 which is gone in cfengine-3.5.0...there's a libpromises.so.3.

Though before I discovered this problem, I first wanted to make some tweaks to update.cf so that I would have some indication that it had copied up new binaries from /usr/local/sbin to /var/cfengine/bin, since I noticed that files there newer than expected. Though I probably just rebuilt the same version port because a dependency had updated and /usr/ports/UPDATING indicated that I need to do that.

This probably is why at work, the person that setup our cfengine 2 went to extreme effort to create static cfengine executables...ignoring that such things are officially not supported on Solaris. Though we seemed to get away with running those executables, built on a Sol10u3 sun4u system...on systems more current up to Sol10u11, and a few Sol11 systems and systems that are sun4v architecture.

In a past life...we had run into a statically built executable (the installer) not working on our first UltraSPARC-III system (Sun v280r)...trying to recall what our build machine was back then.... my recollection says we only had the SPARCserver 20 and SPARCstation 10, before that. Though as I recall, we had to wait for a patch from Sun as well as rebuild the executable shared on the SPARCserver 20...to have it work. It wasn't long after that though that we retired support for sun4m, changing minimum requirements. Wonder if the application has become 64-bit yet? But, for ABI backwards compatibility claim to work, the executable needs to be built shared...so that it'll find the libraries provided on newer systems to allow older executables to still work.....

portmaster probably didn't know that it should save /usr/local/libexec/cfengine/libpromises.so.1, though would the old executables know how to find the library when its moved aside? (I do have SAVE_SHARED=wopt uncommented in my portmaster.rc file).

Occurs to me that I could just restore the file from backup, it would allow me to run


and get me to where everything should work again.

Though before I did that, I had invoked cf-promises (the one in my path -- /usr/local/sbin), and it complains about library.cf. Guess it doesn't like the old cfengine_stdlib.cf, the new one isn't where the old one was....it was here instead --> /usr/local/share/cfengine/CoreBase/libraries/cfengine_stdlib.cf I do a quick look at what's in it....mainly to make sure that bundles/bodies that I use are still there...and notice some interesting new ones....such as a package_method of freebsd_portmaster, someday I should look at cfengine3 to do port/package promising....

But first get cfengine working on policyhost, hopefully the other servers (at 3.4.4) are still working.....guess not, 3.4.4 doesn't like the 3.5.0 cfengine_stdlib.cf file. But, cf-promises is also not happy with some of my other promises....

Guess I'll update those while I get policyhost working again.


Or perhaps I need to revert....

root@zen:/var/cfengine/inputs 317# cf-agent
2013-06-15T13:22:53-0500    error: Bundle 'crontab' listed in the bundlesequence is not a defined bundle
2013-06-15T13:22:53-0500    error: Fatal CFEngine error: Errors in promise bundles
1.755u 0.113s 0:01.94 95.8%     172+2501k 133+12io 1pf+0w
root@zen:/var/cfengine/inputs 318# 
# cf-agent -v
2013-06-15T14:00:57-0500  verbose: Parsing file '/var/cfengine/inputs/do-crontab.cf'

Its there, why's it not working.... 'cf-agent -d' doesn't work, but it will only do failsafe....

Full story »

  09:12:00 am, by The Dreamer   , 390 words  
Categories: Software, FreeBSD

Perl update continued

For some reason I had cd'd into /usr/local/lib/perl5 on dbox and noticed that 5.16.2 was still present...well 5.12.4 was still on zen after I the upgrade to 5.14.2... and it just had whatis files. But, I went and looked inside, and found more than just whatis files.

Using 'pkg_info -W', I found that I had other ports that had installed perl modules that didn't start with 'p5-' or depend on 'libperl.so'.

So, off to rebuild those ports.

On dbox/cbox it was just databases/rrdtool, print/pdflib...plus some stray files left by already updated ports or removed ports. But, on zen there was a much bigger list of ports:

japanese/p5-Jcode (which was missed, because the package name is ja-p5-Jcode-)

Hmmm, probably need to update my i386 space, which is going to be wrong now...because uses the name make.conf of 'global', and I haven't updated it in a long time.... Not since May 4th. emulators/wine-devel has been updated since then, so I guess I'll have to tackle it sooner than later.... Especially, since I'm thinking of making another attempt to see if I can get other apps running in wine versus VirtualBox....

Full story »


  08:36:00 am, by The Dreamer   , 959 words  
Categories: Software, FreeBSD, CFEngine

Perl update + cfengine3 and subversion == great big mess on FreeBSD

So being up ridiculously early this morning, because I got up at the right time during the night...but forgot to take my second dose, and too late to take it when I woke again.

So, I thought I would tackle updating to the latest perl on zen. Choose not to just do a blind 'portmaster -r perl', since that would include anything that depends on being able to run perl or depends on something that depends on perl...possibly many levels down. Somebody should come up with a simple way to only rebuild the ports that directly depend on another port....

What I decided to do what after updating perl, was 'portmaster p5-*' then do a pkg_libchk to see what ports are missing libperl.so and redo those.

I did this first by logging into my machine at work (mew) and it went quickly and worked pretty cleanly. Though there are only half the number p5- ports, and less ports missing libperl.so as well.

So, back on zen...I updated perl and then started the 'portmaster p5-*', when it stopped. A port is dependent on /usr/local/bin/perl5.14.2, which is not found because I just updated to 5.14.4!

How do you have ports that are dependent on a specific version, especially since its possible to have a different version of perl. When I first installed zen, the default perl was 5.12.x...but I had elected to upgrade to 5.14.x when that became the new default. OTOH, when I setup cbox/dbox, I opted to go with 5.16.x...and at work, mew had started before zen, so it was also 5.12.x initially...but I choose to jump that up to 5.16.x (actually no .x at first, but it was very quickly followed by a .1...which inflicted a lot of pain again....though in this latest update they have switched to just major.minor for module path, which means no more pain until its time to upgrade to a newer minor release....

The first casualty was devel/p5-B-Keywords ...and I find its depended on by textproc/p5-Perl-Critic and textproc/p5-Test-Perl-Critic....with the last port being the leaf. So that seems to be that it was probably just a build depend for something I had installed long ago (since it doesn't sound like anything I could call in any of my own perl scripts.) So, I figure I'll just delete those packages and carry on.

Nope, the next port also fails with the same strange demand.


After hunting around a bit, to try and figure out what is making this port think it depends on the previous version of perl...it dawns on me that the perl port updates /etc/make.conf as to what version of perl is installed.

And, I have


being managed by cfengine3. :oops:

So, I go update the file, and try to svn commit the change....which blows up because the perl modules needed for the commit hook haven't been updated yet.

Well, guess I'll stop cfengine3 from reverting my /etc/make.conf (by disabling the promise from the root side) Though IIRC now, the commit hook is mainly to prevent root from doing commits into my subversion repository, instead of the put subversion on an NFS filesystem and have rootsquash prevent root from being able to write into the repository, that we do at work.

Phew....I can commit updated /etc/make.conf and let cfengine promise it. Perhaps in a future project, I'll see if there's some way to have cfengine set that dynamically or something.

Though should I have cfengine promising all of /etc/make.conf ? There's a block in /etc/make.conf that is the same across all my FreeBSD systems, since its the ports that I come across that don't like 'make -j#'. And, it was intended to have cfengine promise that part, though it there have been other additions that I want the same on all my FreeBSD systems, like the override on modules in net-snmp, that I mention when I ran into some cacti. Though there's value in having cfengine having the whole file....or rather its that the files are in subversion.

Next up...nagios has alerted me that spamassassin has stopped, yeah, I guess that would happen. Which means there's going to be a big chunk of spam in all my mailboxes (126...I need to find a good way to aggregate them back so that I can read them all ... from roundcube) module rebuilds are done, and spamassassin seems to be running again (probably because cfengine3 has a promise to keep for that) Though might work better if I do an 'sa-compile' to make sure that part is right...though seemed to me it was only major.minor....

Full story »


  07:05:00 pm, by The Dreamer   , 2118 words  
Categories: Software, Computer, BOINC, FreeBSD

sqlite3 SECURE_DELETE and Firefox

So a few days ago, databases/sqlite3 was updated in ports. And, in the portmaster run, I was faced with its config dialog. Think I had gone with the defaults previously, but decided to take a closer look this time. Saw that SECURE_DELETE, with the description "Overwrite deleted information with zeros". That sounds like a waste of time, I should probably turn that off.

A quick online search, I found this:

The secure_delete setting causes deleted content to be overwritten with zeros. There is a small performance penalty for this since additional I/O must occur. On the other hand, secure_delete can prevent sensitive information from lingering in unused parts of the database file after it has allegedly been deleted.

Yup, definitely just a waste of time...even says so. The OTOH, wrong. Why? Because I'm running my FreeBSD system on ZFS, which is copy-on-write. Its just spinning my wheels create a new copy of the file filled with zeros, and the old file is just unlinked somewhere intact, and then unlinking that new copy that it had filled with zeros. When just unlinking the old file achieves the same thing faster.

Of course, what happens a little while later there's an update to www/firefox in ports, where the configure fails because sqlite3 wasn't built with SQLITE_SECURE_DELETE. Well, I'm not turning on stupid for Firefox...I'm already disappointed by how slow it has become (and PGO seems to be broken again), to where chrome/chromium is now my everywhere browser. Which is working on the most part now that I don't have a Solaris workstation as part of my everywhere.

Well, its just configure that is testing for it and complaining...so there should be a way to turn it off. Hmmm, no option to do that, guess I'll have to later the configure script. Do I inject a patch into the files directory? Looks like the file is being adjusted elsewhere, though I don't see a patch in files that is working on it. Okay, its the post-patch target in the Makefile. Can I just add to that? Guess the way to do it is to change AC_MSG_ERROR to something that doesn't terminate the configure. Unfortunately I have portmaster.rc opertion "PM_DEL_BUILD_ONLY=pm_dbo" uncommented, so can't quickly look what AC_MSG_??? I could use. Find some online documentation, that describes AC_MSG_CHECKING, AC_MSG_RESULT, AC_MSG_NOTICE, AC_MSG_ERROR, AC_MSG_FAILURE, AC_MSG_WARN...first 3 are messages that aren't emitted if '--quiet' or '--silent' options are used. I don't think those options are used normally, but seems like a good idea to me. I'll use AC_MSG_NOTICE (though now that think of it, AC_MSG_RESULT is probably valid, since it was an AC_MSG_CHECKING that comes before the AC_MSG_ERROR...)

Well, AC_MSG_NOTICE is undefined. Guess the autoconf being used is different than the one I found online. AC_MSG_ERROR and AC_MSG_FAILURE cause exits, but AC_MSG_WARN writes to stderr and continues. Guess, that's what I'll have to use then.

So, I insert the change, and create quick diff so that I can reapply it as a patch for next time....


--- Makefile.orig  2013-06-03 17:45:05.000000000 -0500
+++ Makefile  2013-06-04 18:22:37.335175851 -0500
@@ -89,6 +89,7 @@
  @${REINPLACE_CMD} -e '/MOZPNG/s/=[0-9]*/=10511/' \
    -e '/^SQLITE_VERSION/s/=.*/=' \
+    -e '/with SQLITE_SECURE_DELETE/s/_ERROR/_WARN/' \

Pages: 1· 2

Now instead of subjecting some poor random forum to a long rambling thought, I will try to consolidate those things into this blog where they can be more easily ignored profess to be collected thoughts from my mind.

Latest Poopli Updaters -- http://lkc.me/poop


There are 20 years 5 months 27 days 1 hour 22 minutes and 2 seconds until the end of time.
And, it has been 4 years 7 months 1 day 12 hours 40 minutes and 54 seconds since The Doctor saved us all from the end of the World!


July 2017
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


  XML Feeds

Who's Online?

  • Guest Users: 36
This seal is issued to lawrencechen.net by StopTheHacker Inc.
powered by b2evolution

hosted by
Green Web Hosting! This site hosted by DreamHost.

monitored by
Monitored by eXternalTest
SiteUptime Web Site Monitoring Service
website uptime