<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Michael,<div><br></div><div>That sounds great! Can't wait to try it out. Thanks!<br><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="font-weight: normal; "><br class="Apple-interchange-newline">--</div><div><b>Matt James</b></div><div style="font-weight: normal; "><a href="http://rainstorminc.com">RainStorm, Inc</a></div><div style="font-weight: normal; ">(207) 866-3908 x54</div></span></div></span></div></div></div></div></div>
</div>
<br><div><div>On Apr 23, 2014, at 6:13 PM, Michael Stauber <<a href="mailto:mstauber@blueonyx.it">mstauber@blueonyx.it</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Eric, hi Matt,<br><br>I'm combining my reply to your two separate topics regarding wildcards<br>and SPF. It's a slightly longer rant. :p<br><br>SPF:<br>====<br><br>Let me start with SPF, because it's a bit easier to answer. As you know,<br>SPF records are simply TXT DNS records that are "tacked on". If you know<br>the right Syntax, you can already go ahead and can use SPF records on<br>5106R/5107R/5108R as is. Just create a TXT record with the proper<br>payload via the GUI and you will be fine.<br><br>Pages such as <a href="http://www.spfwizard.net/">http://www.spfwizard.net/</a> sure are a great help finding<br>out how the Syntax for your SPF record(s) should look.<br><br>However, this usually overlooks some fundamental stuff. What about<br>emails from localhost? Which would mean system generated emails, mails<br>from certain scripts and so on. So you *will* need to think your SPF<br>record layout through thoroughly to really match all usage cases.<br><br>Sure, having pages in the BlueOnyx GUI that *assist* with creating<br>proper SPF records would be nice. But such a wizard is quite complex and<br>at the end of the day there will be usage cases that it won't and can't<br>cover. That's where your own brain juice is again needed.<br><br>If I wanted to do such a wizard, it would take me four weeks. Minimum.<br>And once I release it, people will come forward and point out all the<br>juicy usage cases where it doesn't work right. So we're looking at<br>another two or three weeks of tweaking it beyond that.<br><br>I'm like *THIS* close (imagine me holding thumb and index finger 3mm<br>apart) of having the new BlueOnyx 520XR GUI done. I *really* don't want<br>to delay the release (or complicate it unnecessarily) with an SPF<br>implementation that will be riddled with bugs and limited in capability.<br><br>Asking me to implement that now is inviting failure. The new GUI will<br>already have sufficient bugs and deficiencies that need to be weeded out<br>through thorough testing before it can be considered stable.<br><br>So long reply for a short answer: Yes, one of these days BlueOnyx will<br>have a basic Wizard to do SPF records. In the meantime (and until that<br>happens) you can create SPF records by doing normal TXT records in the<br>DNS GUI.<br><br>Wildcards for hostnames:<br>========================<br><br>I just shot my development box for 520XR six ways 'til Sunday *trying*<br>to get this work. I'll actually have to restore it from a backup before<br>I can continue development. Aside from loosing time with the restore,<br>I'll also have to merge changes back into the backup that I did since<br>the last backup run. Fun and games - half a day wasted.<br><br>Let me explain some of the basics of Sausalito here. Not much, but<br>little enough to understand the problem I'm facing there:<br><br>CODB database fields can only take data that matches a certain scheme.<br>We can define these types of data that a field can take with regular<br>expressions.<br><br>For example:<br><br>username:<br><br>That field only takes alphanumerical characters plus a limited subset of<br>other characters. Such as ".", "_" and "-". That's defined in a schema<br>file like this:<br><br><typedef<br><span class="Apple-tab-span" style="white-space:pre"> </span>name="alphanum_plus"<br><span class="Apple-tab-span" style="white-space:pre"> </span>type="re"<br><span class="Apple-tab-span" style="white-space:pre"> </span>data="^[A-Za-z0-9\\._-]+$"<br>/><br><br>You can see, the regular expression for this is: ^[A-Za-z0-9\\._-]+$<br><br>In a CODB Schema file for a data-field that should contain the username,<br>we can then simply define that field like this:<br><br> <property<br> name="username" type="alphanum_plus" default=""<br> writeacl="ruleCapable(modifyUserDefaults)"<br> /><br><br>And CODB will then make sure that only data is stored into that field<br>that matched the regular expression we defined for "alphanum_plus".<br>Likewise the new GUI will also check input with this *while* you type it<br>into the respective form field. If the entered data doesn't match<br>validating against "alphanum_plus", you get an error message.<br><br>Which is all nice and comfy. It's a real time saver when coding GUI<br>pages, as you don't have to worry about the user submitting data that<br>doesn't belong into the respective fields.<br><br>Now let me come to "hostname", "domainname" and "fqdn". They are also<br>defined in Schema files and the regular expressions for that are already<br>horribly complex.<br><br>So I *can* tweak the "hostname" field to accept a wildcard instead.<br><br>At the moment the definition for "hostname" looks like this:<br><br><typedef name="hostname" type="re"<br> data="^[A-Za-z0-9][A-Za-z0-9\-]*(\\.[A-Za-z0-9][A-Za-z0-9\-]*)*$"<br>/><br><br>If I change it to also accept a wildcard, it'll look like this:<br><br><typedef name="hostname" <span class="Apple-tab-span" style="white-space:pre"> </span>type="re"<br><br>data="(^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])$)|(^\\*$)"<br>/><br><br>Yes, that is a hell of a lot more complicated, but it does the trick. It<br>probably can be simplified a bit further, but ... I'm in a hurry.<br><br>Ok, so far so good. Now *all* "hostname" fields in *each* and *every*<br>part of the GUI accept wildcards. Let us think for a moment if that's a<br>smart idea. Where are we using these?<br><br>- Vsite Add: We can create Vsites with a hostname of "*".<br>- Vsite Mod: We can change the hostname of Vsites to "*".<br>- DNS Management: We can create DNS records with "*" for the hostname.<br>- Email aliases: Email server aliases with "*" for hostname.<br>- Web aliases: Web server aliases with "*" for hostname.<br>- SSL certificates: Can now contain a wildcard in hostname, too.<br><br>So with DNS we're good. We want wildcard DNS. We might also want<br>wildcard web server aliases.<br><br>What we do NOT want is email server aliases *and* Vsites themselves that<br>have a wildcard in their name.<br><br>Which now immediately creates a problem: ALL our "hostname" input fields<br>in the entire GUI now accept wildcards. Because every GUI page and every<br>Schema file that deals with hostnames is now hot-wired to accept<br>wildcards. Even for the parts where we don't want them.<br><br>In a lot of places the FQDN is also assembled out of "hostname" and<br>"domainname", which have separate definitions. And FQDN has a separate<br>definition of what data is allowed and which not. So if the hostname<br>*has* a wildcard is merged with the domainname into an FQDN, then the<br>storage of the data will fail. Because FQDN can't take wildcards in the<br>hostname part according to our CODB data-type definitions.<br><br>But hey, it gets worse: We have Perl handlers which update the email and<br>webserver configuration. Also proftpd.conf. If I feed those Perl<br>handlers wildcard hostnames, they blow up. Because they're not designed<br>to have a wildcard in the data. Wildcards, which could or could not be<br>(depends on the context) be interpreted as a regular expression itself.<br><br>Just three examples:<br><br>a.) FQDN contains a wildcard:<br><br>Handler base_unique.pl blows up while verifying if another site exists<br>that already might contain that name. The handler to create the email<br>server mapfiles triggers after it and blows up, too. Instant hang up of<br>CODB and further transactions via the GUI aren't possible until the<br>haning processes are killed and CCEd is restarted.<br><br>b.) Email server alias contains a wildcard:<br><br>See above. One of the handlers for creating the email server mapfiles<br>doesn't handle this well.<br><br>c.) Web server alias contains a wildcard:<br><br>Handlers work fine and the changes go through as intended. Except that<br>Apache won't restart because the /etc/httpd/conf/vhosts/site* file now<br>contains a syntax error:<br><br># owned by VirtualHost<br>NameVirtualHost 208.77.221.197:80<br><br># ServerRoot needs to be set. Otherwise all the vhosts<br># need to go in httpd.conf, which could get very large<br># since there could be thousands of vhosts:<br><br><VirtualHost 208.77.221.197:80><br>ServerName <a href="http://www.basura2.net">www.basura2.net</a><br>ServerAlias <a href="http://basura2.net">basura2.net</a> *.<a href="http://basura2.net">basura2.net</a><br>ServerAdmin admin<br>DocumentRoot /home/.sites/70/site4/web<br>ErrorDocument 401 /error/401-authorization.html<br>ErrorDocument 403 /error/403-forbidden.html<br>ErrorDocument 404 /error/404-file-not-found.html<br>ErrorDocument 500 /error/500-internal-server-error.html<br>RewriteEngine on<br>RewriteCond %{HTTP_HOST} !^208.77.221.197(:80)?$<br>RewriteCond %{HTTP_HOST} !^<a href="http://www.basura2.net">www.basura2.net</a>(:80)?$ [NC]<br>RewriteCond %{HTTP_HOST} !^<a href="http://basura2.net">basura2.net</a>(:80)?$ [NC]<br>RewriteCond %{HTTP_HOST} !^*.<a href="http://basura2.net">basura2.net</a>(:80)?$ [NC]<br>[...]<br><br>In the last line above you see the Rewrite-Condition containing the<br>wildcard. The * in it needs to be escaped like this:<br><br>RewriteCond %{HTTP_HOST} !^\*.<a href="http://basura2.net">basura2.net</a>(:80)?$ [NC]<br><br>So that handler needs an extra IF-clause to check web server aliases for<br>wildcards. And if present, it needs to escape them. Great! \o/<br><br>Long story short:<br><br>To allow wildcard hostnames we need:<br><br>- Updated basetypes.schema with EXTRA definitions for:<br><span class="Apple-tab-span" style="white-space:pre"> </span>- hostname with and without wildcards<br><span class="Apple-tab-span" style="white-space:pre"> </span>- FQDN with and without wildcards in the hostname part<br><br>- Updated base-dns.mod:<br><span class="Apple-tab-span" style="white-space:pre"> </span>- DNS.schema needs an update to change the datatype for<br><span class="Apple-tab-span" style="white-space:pre"> </span>"hostname" to "hostnamePlusWildcard".<br><span class="Apple-tab-span" style="white-space:pre"> </span>- GUI pages for DNS management (server + Vsite) needs<br><span class="Apple-tab-span" style="white-space:pre"> </span>changes to change input-validation for "hostname" to<br><span class="Apple-tab-span" style="white-space:pre"> </span>"hostnamePlusWildcard". That's like 9 GUI pages that<br><span class="Apple-tab-span" style="white-space:pre"> </span>need changes.<br><br>- Updated base-vsite.mod:<br><span class="Apple-tab-span" style="white-space:pre"> </span>The following GUI pages need input validation for "hostname"<br><span class="Apple-tab-span" style="white-space:pre"> </span>changed to "hostnamePlusWildcard":<br><span class="Apple-tab-span" style="white-space:pre"> </span>- "Site Management" / "Web"<br><span class="Apple-tab-span" style="white-space:pre"> </span>- "Site Management" / "Add Site"<br><span class="Apple-tab-span" style="white-space:pre"> </span>- "Site Management" / "Site Template"<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Vsite.schema needs to be updated.<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Various handlers need to be updated.<br><br>- base-ssl.mod:<br><span class="Apple-tab-span" style="white-space:pre"> </span>Don't get me started on this one. Changes needed?<br><span class="Apple-tab-span" style="white-space:pre"> </span>- In 5 GUI pages.<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Probably two schema files<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Various handlers and constructors<br><span class="Apple-tab-span" style="white-space:pre"> </span>- PLUS the script that dynamically creates the SSL-containers.<br><br>- base-email.mod:<br><span class="Apple-tab-span" style="white-space:pre"> </span>I'd be damned if I knew. Can't even tell where and where not<br><span class="Apple-tab-span" style="white-space:pre"> </span>I'd have to make changes. Probably various handlers and<br><span class="Apple-tab-span" style="white-space:pre"> </span>constructors. Maybe a schema file or two.<br><br><br>My bottom line:<br>===============<br><br>Yesterday I thought I'd be able to finish the new BlueOnyx GUI this<br>week. With *that* dumped into my lap we're looking at a 4-6 week holdup<br>plus a lot more potential bugs in critical subsystems.<br><br>So I'm offering a compromise here: The new GUI will allow wildcard DNS<br>records. It will also allow that "web server alias" contains a wildcard<br>in the hostname (see attached screenshots).<br><br>But that's it. Neither FQDN's (for Vsite names) or email server aliases<br>will take wildcards.<br><br>It'll still require a few days of tweaking and testing before I can be<br>comfortable with it. And this will *NOT* make it into 5106R, 5107R or<br>5108R. It'll only be in BlueOnyx models with the new GUI (5207R/5208R -<br>or better).<br><br>Good enough?<br><br>-- <br>With best regards<br><br>Michael Stauber<br><span><Bildschirmfoto vom 2014-04-23 15:51:50.png></span><span><Bildschirmfoto vom 2014-04-23 15:51:43.png></span>_______________________________________________<br>Blueonyx mailing list<br><a href="mailto:Blueonyx@mail.blueonyx.it">Blueonyx@mail.blueonyx.it</a><br>http://mail.blueonyx.it/mailman/listinfo/blueonyx<br></blockquote></div><br></div></body></html>