freiheit's questions

I'm trying to build an RPM, but the source file from the vendor has a space in the filename, and there doesn't seem to be any good way to escape the filename so that it builds.

I've tried putting a \ in front of the spaces. I've tried replacing them with %20. I tried +. I've tried putting "s around it, I've tried ' around it.

For now, I'm working around it by renaming the source file from the vendor to not have spaces, but I really prefer to leave original vendor source filenames intact whenever possible.

With no escaping or quoting, I get:

+ unzip .../Foo Bar.zip
unzip:  cannot find or open .../Foo, .../Foo.zip or .../Foo.ZIP.

With \, the unzip works, but then:

error: Bad file: .../Foo\ Bar.zip: No such file or directory

Here is a fully functional test.spec file (I did zip "Foo Bar.zip" test.spec to get a sample zipfile):

Summary: Test
Name: test
Version: 1
Release: 1
License: Whatever
URL: http://www.example.com/
Source1: Foo Bar.zip

%description
Just a test of escaping stuff...

%prep
%build
%install
%{__install} -d -m0755 %{buildroot}/foo
cd %{buildroot}/foo
unzip %SOURCE1

%clean
%{__rm} -rf %{buildroot}

%files
/foo

%changelog
* Wed May 8 2013 Example <[email protected]>
- Whatever

Is there any way to restrict a mailman mailing list to only allowing subscriptions from one specific domain?

I know how to ban specific email addresses or domains from subscribing, but is there a way to ban all domains that aren't, say, example.com? Or maybe a couple specific domains?

We're starting to get hit by subscription attempts to some of our lists from what I'm sure are spammers on botnets¹ and it's annoying list owners. Some lists are configured with a subscribe_policy of "Require approval" or "Confirm and approve" because the lists are intended to be only for our local users and it would be nice to minimize the annoyance of the list owners by automatically rejecting subscriptions from outside email addresses that won't be allowed to subscribe by the list owner anyways.

We can't simply restrict access to the local networks because we have lists intended for a worldwide audience and some of our "local" users can be anywhere.

¹ One email address subscribes to a couple dozen unrelated lists from different IPs over a few hours; then the next day another round with a new email address and different IPs. In a few cases list owner has emailed them a question about why they were signing up for the list and received no reply.

On our HP servers, HP provides an image we can put on a USB key (or CD), boot from and patch the all the firmware in the system. On our Linux Dell servers there's a convenient yum repository we can set up in a few simple steps (I use puppet) to put firmware updates in place. Similar for windows, but I don't manage those. But on our Dell VMware ESX servers, we don't have any easy way to update firmware. We can go through a bunch of effort to find out the latest versions of every firmware on the system, download those and install them individually. But we can't easily just update all firmware in need of an update.

We like to check if there's firmware updates roughly quarterly, along with the rest of the "patch to current whether we need it or not" OS patches, but have been letting the Dell ESX servers fall out of date.

Anybody figured out an easy way to update all the firmwares (BIOS, RAID card, NIC, DRAC, etc.) in a Dell server on ESX, or without any OS support?

We're working on a project to migrate employee email from Unix/open-source (courier IMAP, exim, squirrelmail, etc) to Exchange 2010, and trying to figure out options for single-signon for Outlook Web Access. So far all the options I've found are very ugly and "unsupportable", and may simply not work with Forefront.

We already have JA-SIG CAS for token-based single-signon and Shibboleth for SAML. Users are directed to a simple in-house portal (a Perl CGI, really) that they use to sign in to most stuff. We have an HA OpenLDAP cluster that's already synchronized against another AD domain and will be synchronized with the AD domain Exchange will be using. CAS authenticates against LDAP. The portal authenticates against CAS. Shibboleth authenticates with CAS but pulls additional data from LDAP. We're moving in the direction of having web services authenticate against CAS or Shibboleth. (Students are already on SAML/Shibboleth authenticated Google Apps for Education)

With Squirrelmail we have a horrible hack linked to from that portal page that authenticates against CAS, gets your original plaintext password (yes, I know, evil), and gives you an HTTP form pre-filled with all the necessary squirrelmail login details with javaScript onLoad stuff to immediately submit the form.

Trying to find out exactly what is possible with Exchange/OWA seems to be difficult. "CAS" is both the acronym for our single-signon server and an Exchange component. From what I've been able to tell there's an addon for Exchange that does SAML, but only for federating things like free/busy calendar info, not authenticating users. Plus it costs additional money so there's no way to experiment with it to see if it can be coaxed into doing what we want.

Our plans for the Exchange cluster involve Forefront Threat Management Gateway (the new ISA) in the DMZ front-ending the CAS servers.

So, the real question: Has anybody managed to make Exchange authenticate with CAS (token-based single-signon) or SAML, or with something I can reasonably likely make authenticate with one of those (such as anything that will accept apache's authentication)? With Forefront?

Failing that, anybody have some tips on convincing OWA Forms Based Authentication (FBA) into letting us somehow "pre-login" the user? (log in as them and pass back cookies to the user, or giving the user a pre-filled form that autosubmits like we do with squirrelmail). This is the least-favorite option for a number of reasons, but it would (just barely) satisfy our requirements. From what I hear from the guy implementing Forefront, we may have to set OWA to basic authentication and do forms in Forefront for authentication, so it's possible this isn't even possible.

I did find CasOwa, but it only mentions Exchange 2007, looks kinda scary, and as near as I can tell is mostly the same OWA FBA hack I was considering slightly more integrated with the CAS server. It also didn't look like many people had had much success with it. And it may not work with Forefront.

There's also "CASifying Outlook Web Access 2", but that one scares me, too, and involves setting up a complex proxy config, which seems more likely to break. And, again, doesn't look like it would work with Forefront.

Am I missing something with Exchange SAML (OWA Federated whatchamacallit) where it is possible to configure to do user authentication and not just free/busy access authorization?