This is an update to the "ddclient & squid" here
Ran into a new problem recently....though the need for SSL in squid on ubuntu is deprecated, by the fact that I'm slowly replacing this server with a FreeBSD server.
As a result, I don't pay attention to this ubuntu server as much as I used to, so I've configured unattended-upgrade. It was installed, but it didn't seem to do anything in that on other servers I'd log in to find that there are lots (40+) of patches available and more than half that are security. Since I came across how to configure it to do more than just security patches, including send me email and on some systems automatically reboot when necessary. (should've thought to see how unattended-upgrade is configured and doing such things in the Ubuntu AMI I have in AWS)
Since I got unattended-upgrade configured on this old server (32-bit Ubuntu Server, which I've heard they have a 12.04LTS download for??? They had said they dropped 32-bit server support, so there was version with 10.04LTS. So I couldn't upgrade and now I'm way past EOL, which is causing problems...probably need to hunt down the landscape and ubuntuone services and nuke them, instead of letting them degrade my server for being EOL.) I've also had to update packages on here from outside sources to keep things running, so guess I should work harder on abandoning this server.... Where it'll likely get reborn as [yet ]a[nother] FreeBSD server....along with the server that I think I have all the parts collected for it, but just need to sit down and put it together. It started as a mostly function pulled 1U server, in need of ... well either new fans or a new case.... I opted for the new case route. It also needed drives and memory. But, as a result of the new case route...aside from case/powersupply...it meant I would need to get heatsinks...since the passive ones based on the 1U case channeling air flow....would be hard to recreate in the tower case I went with. Its a huge tower case, given that its an E-ATX motherboard...yet it isn't a full tower (like the formerly windows machine called TARDIS...someday I'll work its regeneration....need money to buy all the bits and pieces that'll make that up, which I haven't fully worked out what those will be....or where it'll go since my dual 23" widescreen FreeBSD desktop has consumed all of the desk that it would've shared....and not really keen on the idea of a KVM for this situation. )
Anyways...every day I get an email from unattended-upgrade for this system.... with:
Unattended upgrade returned: True Packages that are upgraded: squid-common Packages with upgradable origin but kept back: squid squid-cgi Package installation log: Unattended-upgrades log: Initial blacklisted packages: Starting unattended upgrades script Allowed origins are: ["['Ubuntu', 'heron-security']", "['Ubuntu', 'heron-updates']"] package 'squid' upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) Packages that are upgraded: squid-common Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg_2013-07-06_08:05:42.056193.log' All upgrades installed
This is because of that quirk where even though I rebuilt my version with SSL, and kept it the same version...it wants to install its version to replace mine (of the same version). Which is why I did the hold thing.
I could do the alternative of add a string to make my version advance from current....though I suppose I won't unhold...so that unattended-upgrade won't upgrade should such a thing appear (unlikely since both the OS and squid are ancient...and there'll be no more updates.) But, the intent is to hopefully silence unattended-upgrade in this matter.
Though kind of surprised its still doing something....hmmm, guess there was a new security patch to squid 2.7 back on January 29, 2013....that I've been missing (suppose its already downloaded the update in its 'cache'....or the backend is still there, its just not getting updates beyond what's there....whatever, I think I'm down to one more service to move off....)
This weekend, I decided it was time that I checked on port updates in my
/compat/i386 FreeBSD 'system'. Which primarily exists to provide me some ports that don't build on 64-bit, namely emulators/wine-devel and net/nxserver. Don't recall the last time I used nx since I got it working, probably should check to see whether it is still working or not (probably okay on my home system, but might be broke on work one....and might see about setting it up on other work computer too).
Hmmm, hadn't updated ports since May 5th. Start with working through
/usr/ports/UPDATING, run into a problem that on 20130609: AFFECTS: users of audio/flac and any port that depends on it, in that there it thinks perl depends on it (kind of an annoyance I have with dependencies....there can be miles of separation between one port and another port, but everything get's marked as depending on that very bottom port, when it in fact didn't or doesn't... Was annoying in trying to figure out why a port was marked BROKEN / DEPRECATED and not get any attention except that people should stop using it...when 100's of ports on my system depend on it. When it turns out that its one or two ports, had an option set that caused it to depend on it. While the other ports generally don't care what options are enabled in that port, just that the command exists for it...or other reason. Though there are some ports that do care about what options were used, which I had ranted about earlier...and I ran into Thunderbird also having that dependency, resulting in this kluge patch:
But, I let the
portmaster -r flac run aways, with the suspicion that it would break later because perl modules that depend on perl (and not flac) wouldn't get picked up as needed to be re-installed or upgraded, due to 20130612: AFFECTS: users of lang/perl* and any port that depends on it. But, would break the re-install or upgrade of a port somewhere and abort. Which is what I found when I checked on it this morning.
So, I did a
portmaster -R -r perl, and noticed that it seemed to include most of the ports that the previous
portmaster hadn't done. In fact it included all of them. I also peeked in
/usr/local/lib/perl5/site_perl/5.14.2 to see what perl modules had gotten missed....mainly the p5-XML-* ones that caused the previous
portmaster to abort.
Though I probably should've looked to see if the second
portmaster was going to address those, instead of doing them while it was asking to proceed. Because that caused it to abort when re-installing those perl modules (that I had done while it was waiting), but restarting it got things done.
That leaves the latest entry 20130627: AFFECTS: users of ports-mgmt/portmaster, which is just informational and not currently applicable.
Before running in to the flac entry, there had been "20130527: AFFECTS: users of lang/ruby18" which was pretty straight forward, since it only exists as a dependency to
ports-mgmt/portupgrade, which I seldom use now...but I have other scripts that use binaries that come as part of it (namely
portsclean), which I could probably replace with the
portmaster way or something else. But, its not really a priority, plus who knows if I won't decide to go back to using
portupgrade...which has options in its
pkgtools.conf that I haven't found equivalents for with
portmaster, though isn't currently an issue right now. Except perhaps that I'm holding back on updating to the latest
emulators/virtualbox-ose, since I've gotten warnings from various sources to stay away from it.
The other big one is what's the
portmaster equivalent to
Will eventually run into a port that has a line one of these:
Where I'm using
Somehow expected there would be more than 12 ports wanting either client or server... probably missing the occurrences in multiline RUN_DEPENDS or some other way to specify the depend. Since pkg_info says there are 103 ports that depend on the client, and two ports that depend on the server (neither being
mail/roundcube, which are the ports that I'm running on 'zen' using the mysql server. On cbox, there are 73 ports that depend on it, some are obviously true...like
net-mgmt/cacti-spine, but nothing is depending on the server...though it is obviously being used by cacti. I left dbox with the default
databases/mysql55-client...there are 71 ports depending on it.
Meanwhile I have postgres server running on zen, which was a depend of something else that I had since removed....but I haven't stopped or removed postgres yet....
In fact after dealing with ruby, flac and perl....the only ports left to update are:
dialog4ports-0.1.3 < needs updating (index has 0.1.5_1)
freeglut-2.8.0 < needs updating (index has 2.8.1)
portmaster-3.16 < needs updating (index has 3.17)
Might be time to see what else I can get working under wine.
Wonder when I had last updated ports in the
/compat/i386 on my system at work? And, do I want to tackle that from home, on a Sunday instead of other important tasks/projects....
But first...lets see what port got updated since yesterday....
Odd, I seemed to have missed updating to
lang/ruby18 on cbox and dbox....
Latest Poopli Updaters -- http://lkc.me/poop
|<< <||> >>|
linux cfengine3 cox cpap amazon.com «watch instantly» «powersource 400» tardis staples mdadm ups «amazon prime» b2evolution ebay woot «windows xp» «doctor who» replaytv «tivo hd» «air purifier» upgrade «hd movie» tv dsl migration freebsd lhaven box ubuntu «windows 7» raid1 prescription progressive 10.04lts «chicago tardis» orac boinc twitter zen tivo backuppc virtualbox raid appletv netflix «instant streaming» dvd eyeglasses «sans digital» usb