You are here

freebsd

"No active remote repositories configured." running pkg in jail

Copy /etc/pkg/FreeBSD.conf from the host to the jails

freebsd-update will not upgrade from 9.0-RELEASE

When attempting to update from a fully-patched 9.0-RELEASE, you may encounter results like these:

Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 9.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

WARNING: This system is running a "venus" kernel, which is not a
kernel configuration distributed as part of FreeBSD 9.0-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install".

The following components of FreeBSD seem to be installed:
src/src world/base world/doc

The following components of FreeBSD do not seem to be installed:
kernel/generic world/games world/lib32

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.

The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.

You will find lots of people telling you to run this command

sed -i '' -e 's/=_/=%@_/' /usr/sbin/freebsd-update

It won't work. Instead you need to apply this patch:

Index: freebsd-update.sh =================================================================== --- freebsd-update.sh (revision 265210) +++ freebsd-update.sh (working copy) @@ -1110,7 +1110,7 @@ fetch_metadata_sanity () { # Some aliases to save space later: ${P} is a character which can # appear in a path; ${M} is the four numeric metadata fields; and # ${H} is a sha256 hash. - P="[-+./:=%@_[[:alnum:]]" + P="[-+./:=%@_~[[:alnum:]]" M="[0-9]+\|[0-9]+\|[0-9]+\|[0-9]+" H="[0-9a-f]{64}"

Server error: '501 5.1.3 Bad recipient address syntax'

A user of my mail server recently had some recipients of a message returned. He received this message from my server.

The following recipient(s) cannot be reached:

       'redacted@civ.utoronto.ca' on 8/20/2014 10:35 AM
             Server error: '501 5.1.3 Bad recipient address syntax'

       'redacted@wlu.ca' on 8/20/2014 10:35 AM
Server error: '501 5.1.3 Bad recipient address syntax' 'redacted@uoguelph.ca' on 8/20/2014 10:35 AM
Server error: '501 5.1.3 Bad recipient address syntax' 'redacted@uoguelph.ca' on 8/20/2014 10:35 AM
Server error: '501 5.1.3 Bad recipient address syntax' 'redacted@eng.uwo.ca' on 8/20/2014 10:35 AM
Server error: '501 5.1.3 Bad recipient address syntax'

The other recipients were delivered successfully. On the server-side, Postfix logged:

Aug 20 14:35:17 darwin postfix/smtpd[63431]: warning: Illegal address syntax from 
or087.uwaterloo.ca[129.97.9.53] in RCPT command: <'redacted@uwo.ca'>
Aug 20 14:35:17 darwin postfix/smtpd[63431]: warning: Illegal address syntax from
or087.uwaterloo.ca[129.97.9.53] in RCPT command: <'
redacted@wlu.ca'>
Aug 20 14:35:17 darwin postfix/smtpd[63431]: warning: Illegal address syntax from
or087.uwaterloo.ca[129.97.9.53] in RCPT command: <'
redacted@eng.uwo.ca'>
Aug 20 14:35:17 darwin postfix/smtpd[63431]: warning: Illegal address syntax from
or087.uwaterloo.ca[129.97.9.53] in RCPT command: <'
redacted@grandriver.ca'>

The problem is that these particular addresses were literally enclosed by apostrophes. I don't know why the user's client (Outlook) misformatted these addresses. He confirmed that he did not copy them from another application or change anything at his end.

To fix the problem I configured Postfix to filter and rewrite the address when it is sending commands to other MTAs.

I added to main.cf:

# Strange filtering
smtpd_command_filter = pcre:/usr/local/etc/postfix/command_filter
and created the file command_filter:
# Fix malformed emails that are surrounded in single quotes.
/^RCPT\s+TO:\s*<'([^[:space:]]+)'>(.*)/     RCPT TO:<$1>$2

This fixed this oddity in which RCPT TO commands were not RFC 821-compliant.

postgrey won't start after FreeBSD upgrade

echo 'postgrey_flags="--inet=127.0.0.1:10023"' >> /etc/rc.conf
chown postgrey:postgrey /var/db/postgrey
/usr/local/etc/rc.d/postgrey start

How to install PECL uploadprogress on FreeBSD

You need this PECL extension to be installed if you would like to see an upload progress indicator in Drupal. Installation is easy, but not obvious.

cd /tmp
# Substitute the latest version from http://pecl.php.net/package/uploadprogress
fetch http://pecl.php.net/get/uploadprogress-1.0.3.1.tgz
tar xf uploadprogress-1.0.3.1.tgz
cd uploadprogress-1.0.3.1
phpize
./configure
make build install
echo "extension=uploadprogress.so" >> /usr/local/etc/php/extensions.ini
cd /tmp
rm -R uploadprogress-1.0.3.1

FreeBSD Kitten

FreeBSD kitten

I walked away for a few minutes and apparently the kitten decided to monitor top; then fell asleep.

28 sleeping processes. 1 running process: moused.

Changing or discontinuing a service? Make sure both your clients and staff are in the know.

I have been a customer of iWeb for 5 years. I chose them because they were a Canadian hosting company that offered good value on dedicated servers, and because they supported FreeBSD. Over the years I have leased 5 servers from them concurrently. On February 5 I experienced problems during an OS update and needed help. Instead I got a rude surprise.

 

Hi there, I wanted to send some feedback, and I waited a few days to cool off a bit. :)

I chose iWeb for a few reasons. You are Canadian; you have well-reputed support staff; you support open-source by mirroring many projects; your prices for dedicated servers are affordable; and you support FreeBSD.

You can imagine how frustrated (to put it mildly) I was last week when my server went down after a routine OS patch and I contacted support only to get the answer "we don't offer anymore support for FreeBSD".

I follow iWeb on Twitter, I read the iWeb blog, and I log into the customer hub regularly. Not only had no one thought to contact customers using FreeBSD to give us warning prior to dropping support so we could make other arrangements, but as far as I can tell there was no public announcement whatsoever.

Of course this isn’t about FreeBSD. I’m disappointed that you chose to drop support and it will certainly affect my choice of provider in the future, but I acknowledge that these are usually decisions based on numbers and economics. Perhaps you found it hard to find qualified support staff; perhaps its part of your focus on your smart server product; perhaps there just isn’t enough demand. It’s about being told that you chose not to support me long before I needed your support.

I have considered your managed services in the past, but the main reason I have opted not to subscribe for added support is that anytime I have had a problem that in sysadmin terms is fixable (a broken gmirror that won’t repair, an inconsistent network connection, or in this case an OS patch that conflicted with the hardware) the only solution I am offered is a new hard drive and a reinstall. While I have 10+ years experience as a sysadmin, I look to your staff when I don’t have time, physical access, or patience to deal with a problem.

In this case, as you can see in the ticket, after I was told that the OS was no longer supported, my subsequent questions were not even properly considered. When I determined that the NIC that was installed to try to help with the problem was making it worse, I asked that it be removed and was told “You can try to disable the nic in the BIOS. As said earlier, we do not offer any support for FreeBSD. We can re-install your server and connect your old disk via USB to allow you to recover your data.” It took another hour debate of back and forth for them to simply remove the NIC.

Once the second NIC was removed I was again able to boot enough that I could see that when the OS patch was installed, a new driver switched the em0 and em1 interfaces and effectively broke em0. The simple command “freebsd-update rollback” restored the server to its previously working state.

Please use this feedback constructively. I encourage you to contact your customers individually and make a public announcement both about this change in support; and in the future, 3-6 months before dropping support for any other operating systems.

Yvan

The next day an announcement was posted on iWeb's website.


 I received a response a few days later.

Hello Mr. Rodrigues,

Thank you for your feedback to management. Your comments are appreciated.

Please accept our apologies for the treatment of your ticket 6129693, in which you were twice given misinformation about the operating systems we are currently supporting. We can clearly see how this misinformation not only adversely affected the treatment of your issue, but how it has given you a misimpression of iWeb and our attitude towards our clients.

In fact, we do currently support BSD and will continue to do so until April 30th, 2013. This information is currently being disseminated to our clients in advance of the end of life for this product for exactly the reasons you cited in your email; we do not wish for any client to be caught unawares by this change and wish to give ample time for alternate arrangements to be made.

The system administrators who treated your ticket were either uninformed or misinformed on this issue; an grievous error that we assure you will be addressed internally. We are sincerely sorry for this lapse in service and would like to offer you full credit on your current invoice for server  CL-T012-164CL along with our apologies.

Have the issues with the server been successfully resolved at this point, or would you like further assistance from one of senior agents in order to have things as you would like? We would be most happy to have someone help you on this, you have only to give the word.

Please advise if the proposed credit is amenable to you and we can do anything to help.

Sincerely,
Misty


Hello, Misty,

Sorry for not getting back to you sooner -- the e-mail that I have registered with iWeb is a secondary one that is only used for support tickets when my main SMTP server goes down. My main contact is [redacted].

Thank you for this and your previous e-mail in response to my concern about iWeb's discontinuation of FreeBSD support, specifically with concern to that support ticket.

I appreciate the credit for the KVM and the month of service on that server.

I saw that you have since officially made the announcement about discontinuation of support of FreeBSD as well as some older Windows platforms. Please heed my advice in the future that you give 6-12 months notice on future support changes. This is common practice and is what most of your competitors follow. As you can understand, to organizations with a large IT infrastructure, even 3 months is considered short notice, and 1-2 months could incite panic.

It is my understanding that come April 31 my FreeBSD server itself will not be affected but that support or reinstallation will not be offered; that is, I am responsible for all support. Please let me know if this is not the case.

I have a request that I hope you will consider.

It would be of great value to people like myself, both users of widely adopted operating systems such as FreeBSD as well as niche ones (BeOS, other linuxes, etc) if you would offer a "bare-metal dedicated server" program.

The idea is that customers could order a dedicated server and you would connect a DVD drive and KVM for the customer to install the OS of their choice. It would be understood that your only support obligation would be to reconnect the drive and KVM when requested (which you already do) and replace faulty hardware. Customers could send you an installation DVD by courier or perhaps for a small fee such as $25 you could burn an ISO when requested. Perhaps it could come with a "do-it-yourself" support tier that included one emergency KVM hookup per month.

My suggestion would accomplish a few things. (a) it would be very helpful to customers with specialized needs; (b) you would be offering a very unique service in your market -- filling the gap between off-the-shelf leased servers and colocation; (c) it would strengthen your image as a customer-focused company. It could even be marketed with an angle like "Canadians embrace diversity, and so does their most reliable hosting provider".

If this isn't a possibility, the only additional thing I would request is a free month of service for overlap if/when I'm ready to migrate to another supported server.

Thank you.

mod_auth_cas.so: undefined symbol: CRYPTO_THREADID_get_id_callback

Today after updating some ports and restarting apache, CAS stopped working and I got the message:

mod_auth_cas.so: undefined symbol: CRYPTO_THREADID_get_id_callback

This seems to be a regression of an old bug. To fix it, unpack the source code, apply this patch (see diff) and rebuild and reinstall mod_auth_cas.so.

FreeBSD bug i386/176073: Update from 9.0-RELEASE-p3 to 9.1-RELEASE-p0 "breaks" network interface

I discovered this problem while performing a routine binary upgrade from 9.0-RELEASE-p3 to 9.1-RELEASE-p0. I checked UPDATING and there were no warnings about known issues relating to my NIC.

freebsd-update -r 9.1-RELEASE upgrade
freebsd-update install (reboot)
freebsd-update install

After the reboot my primary network interface em0 reported no carrier. To make a long story short, the interface previously known as em1 was now em0 and the interface previously known as em0 was no longer enumerated.

Scrolling back through the console messages showed:

em0: Setup of Shared code failed
device_attach: em0 attach returned 6
pciconf -vl showed that the interface previously enumerated as em0 was now none0

I have read about other similar issues by other people in the forums, but not necessarily with my NIC (Intel Pro/1000). I think the common denominator may be the chipset. As this is a leased server in a datacentre I don't have much to go on except that it is a SuperMicro PDSBM which appears to use the Intel 946GZ
(Lakeport-G). Perhaps something to do with a pci-related driver has changed.

Follow the bug report here.

Bulk labelling volumes in Bacula

My EC2 Bacula storage configuration consists of a single pool containing multiple storage devices. Each storage device is a 100GB EBS store, and each contains a fixed number of prelabelled 1GB volumes.

Here's a little script I whipped together to prelabel the volumes with an incremental identifier.

NAME
    bulklabel -- label new Bacula volumes with incremental names
 
VERSION
    1.0 February 5, 2013
 
SYNOPSIS
    bulklabel <pool> <storage> <start> <count> <prefix>
    bulklabel <pool> <storage> <start> <count>
 
    pool:    name of pool resource
    storage: name of storage resource
    start:   first numerical identifier
    count:   number of volumes to create
    prefix:  optional volume name prefix
 
EXAMPLES
    bulklabel Default FileStorage1 10000 100 Vol-
        will create 100 volumes named Vol-10000, Vol-10001...
    bulklabel Scratch Tape1 20000 50
        will create 50 volumes named 20000, 20001...
 
COPYRIGHT
    (c) 2013, Yvan Rodrigues http://yvanrodrigues.com
              Red Cell Innovation Inc. http://two-red-cells.com
 
LICENSE
    FreeBSD license
    http://en.wikipedia.org/wiki/FreeBSD_License

Pages

Simple Copyright Policy: If you want to reproduce anything on this site, get my permission first.