Statements About Questions Are Not Questions

Statements About Questions Are Not Questions

Here’s a pet peeve of mine: the use of a question mark when you are actually making a statement about your query or curiosity.

For example, I wonder if it will rain tomorrow. Note the lack of a question mark.

Most would write, “I wonder if it will rain tomorrow?” This isn’t a question, it’s a statement.  I wonder if it will rain tomorrow.

If I’m asking a question, I would frame it this way:

“I wonder, will it rain tomorrow?”

I’ve asked an actual question, and therefore I use a question mark. So why does this bother me so much?

Because it’s a sign of intellectual laziness, not of just one person, which is bad enough on its own, but of English speakers as a whole. If people keep doing it, it will become part of the definition of the language to do this, but it flies in the face of logic. The fact that this is a happening isn’t so bad on its own, but it is symptomatic of larger flaws in our society, a sort of erosion of the principles of reason in what we sometimes tout as the Age of Reason.

When I told a friend about my concerns, she said, “My English teacher insisted that was a question and needed the ? mark.”

I replied that her English teacher was quite wrong, and here is why:

The sentence structure belies that. If you replace the object, subject and conjunction but retain the grammatical structure of the sentence, you can derive something like, “I depend on it to rain.” It’s still not a question, and the sentence structure is not a question. There’s no querant in either case. Simply stating “I wonder” does not make it a question, any more than using any other verb in that sentence structure. It’s a statement about wondering, not a question in and of itself.

The word “wonder”, in this case, is a subjunctive verb. The English subjunctive is a special, relatively rare verb form that expresses something desired or imagined. We use the subjunctive mainly when talking about events that are not certain to happen. For example, we use the subjunctive when talking about events that somebody wants to happen, or anticipates will happen.

Statements do not get question marks, therefore the sentence “I wonder if it will rain tomorrow” does not get one. Q.E.D.

The counterpoint to this is that there is a difference between expository writing and dramatic writing. The question mark indicates the tone of the speaking character’s voice, because the character does indeed intend it to be a question.  My friend Joseph Ksander commented:

“This is not a spoken english problem, but a written one. ‘I wonder if it will rain tomorrow’ is in the first person, and has narrative value. And one would argue that the tone of the statement is interrogative (it absolutely is). So when writing, especially in narrative, we are allowed a certain amount (quite a lot) of poetic license to give words and phrases meaning beyond the literal. By giving ‘I wonder if it will rain tomorrow?’ an interrogative mark, we give the reader a hint of how it would sound coming out of a character’s mouth. It has the feeling of a question, and writing is at least as concerned with creating feeling as it is with conveying meaning.”

There is, as Joe points out, a difference between the written word and the spoken word, and using the written word to illuminate the spoken word.

I doubt that my words will have much of an affect. One can only hope that reasonable voices are occasionally heard, but Joe is right, it all depends on context.

I wonder what will happen.

-30-
Forcing Centovacast to Use LetsEncrypt Certificates for SSL

Forcing Centovacast to Use LetsEncrypt Certificates for SSL

Starting with What Made Sense

So the Krypton Radio web site has to go full SSL now because most modern web browsers (read “Google Chrome”) won’t let people visit without warning them that your web site will slay your children in their sleep if you don’t have an SSL certificate on it.

This is frankly just Google messing with our heads, for the most part. A site that does not handle money shouldn’t have to worry about this. All the monetary things we need to do are handled by external sites that actually are secure. But I digress.

So our first assumption was that we could just buy a cert from secureserver.net, install it on Centova, Icecast and our main web server and we were probably good to go.

And then everything collapsed.

What We Did First

I went to create our private key and Certificate Signing Request. After a few tries, I finally was able to use CPanel to generate this, adding in wildcard domains for every domain we wanted to cover. This is a completely legal thing, and you can buy one certificate to handle as many domains as you want.

If you actually buy it through CPanel, though, you can’t. It’s one domain per cert, and $30 per cert. Buying it through your registrar, though, is a lot cheaper.  If you own ten domains, you can easily spend a bundle doing this, and there’s literally no reason for it. Shall we spend 10% of the cost Cpanel wants us to spend?

Yes. Yes we shall.

Mind you, the only reason we’re doing that is that when we started all this there was no such things as Let’s Encrypt, which is a free secure certificate signing company.

The only catch to certificates you get from Let’s Encrypt is that the certificates expire after 90 days, so it’s kind of a problem if you want to use them with a mail server. Every three months your users will have to accept a new SSL certificate to get their email, and trust me, it wigs them out. Most people can barely operate the send button.

That Utterly Failed

No matter what we did with the certificates supplied to us by secureserver.net, Centovacast hated them. The installation script provided by Centova (your installation will tell you that the script lives at /usr/local/centovacast/sbin/setssl) just barfs on it every time.

The instructions provided by Centova say to get Apache credentials. This is wrong. You need credentials for something, but whatever it is, it wants a .pem file, and whatever is supposed to be IN that .pem file isn’t documented.

If you can get a .pem file, great – otherwise, you’ll have to do a massive workaround.

The Icecast Connection

So that’s when we figured out that Icecast, the Centova main panel , and WordPress all needed to be set up with certificates, and that not all of them were going to be able to use the same ones.

Here’s the instructions I found on how to do that for Icecast.

Note with particular attention that they’re talking about putting the private key, the public key, and the authority chain all in one file. I found a BBS topic on how this should be done, specifically with Let’s Encrypt.

(By the way, the whole point of a private key is that it’s supposed to be private. Why are they asking you to do this??)

The Centovacast Connection

I never got the certs I bought working with Centovacast, and self-signing isn’t an option, so I went ahead and asked the Centova Utility  at /usr/local/centovacast/sbin/setssl to create the certs for me using Let’s Encrypt.

To do that, you need to set up a directory alias on a web server on the same domain as Centovacast to serve up the validation files Let’s Encrypt needs to prove that you’re who you say you are.

The instructions say to use a specific block of code to define the directory alias that points to where those validation files are held on the server, but it says nothing about where in your Apache file to put them.

You’re going to need to set up your aliased directory so that the same domain that handles your Centova server is being served as a regular domain or subdomain on port 80, which is the standard port for serving web pages.

In my case, I had a subdirectory called ‘station’. I had to create a server alias so that that subdomain was included in the list of other servers my main vhost listing handles for me, so that my Centovacast subdomain and my main one are really being handled by the same vhost. This saved me from having to set up a complete separate vhost just to handle this one fricking problem.

It also gives the incorrect code to insert in the first place. Forget what they say in their article. Here’s the correct code:

Alias /.well-known/acme-challenge /usr/local/centovacast/etc/ssl/acme-challenges

<Directory “/usr/local/centovacast/etc/ssl/acme-challenges”>
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
Require all granted

# Apache 2.x
<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
</IfModule>

# Apache 2.4
<IfModule mod_authz_core.c>
Order allow,deny
Require all granted
</IfModule>
</Directory>

Big question: Regarding the ‘setssl’ utility, why put broken code in a utility, and then write documentation that pretends it works? Again?

Centova is notorious for this.

When we fixed all of the above basic configuration with the Apache server to satisfy the needs of LetsEncrypt, we found that the setssl script was changing permissions on the target file folder such that it would return a 403 error.

That’s right, the Centova utility script that installs the certificate intentionally breaks the process so that it can’t finish.

Insert the change in the chmod instruction that alters it from 750 to 755.

For some reason this bug has been in there forever, and Centova’s never fixed it. They say the answer to this problem is to make the user that the Apache server runs under a member of the ‘centovacast’ group, but in my experience this didn’t work and I got a 403 error no matter what I did later.

Anyway, here’s the code to modify:

if [ ! -e “$challengepath” ]; then
mkdir -p “$challengepath”
fi

chown root.centovacast “$challengepath”
chmod 0755 “$challengepath”

testcontent=”test-$(date +%s).$$”
testfilename=”${testcontent}.txt”
echo “$testcontent” > “$challengepath/$testfilename”

#(In later versions of the code, these two lines are missing entirely. If they’re present, make the change to the chmod parameter as shown).chown root.centovacast “$challengepath/$testfilename”
chmod 0755 “$challengepath/$testfilename”

Once I patched my copy, I set the file permissions on it so that future Centova updates couldn’t revert my changes, like they did the last three times.

You’re Not Out of the Woods Yet

It’s not enough to get Centova itself running on an SSL certificate. Now you have to get IceCast itself working with SSL, which for some reason is a separate task, and any attempt to link to an unsecured stream from a secured site will make web browsers claim your site is not secure, thereby defeating the whole point of having a certificate in the first place.

So the trick here is, you will probably have to create a new listen socket beyond your default. Centova, by default, set you up on port 8000. I had to create a new secure port, so I moved it well up out of the way, on port 8080. All the mount points are available on both ports, but you can’t have one port be both secured and unsecured.

Your Icecast config isn’t called icecast.xml in a Centova installation. It’s called server.conf, and it’s also in a nonstandard location, which is /usr/local/var/vhosts/<your station name>/etc/server.conf.

Here are the listen socket sections from my server.conf.  It’s the top one you’re looking at. The bottom one is the default definition, and the top one is the secure one. Centova does not support the direct creation of secure listen sockets, so you have to hack this by hand.

<listen-socket>
<port>8080</port>
<ssl>1</ssl>
</listen-socket>

<listen-socket>
<port>8000</port>
</listen-socket>

Then finally, you’ll have to add a line in your server.conf file that loads the required SSL certificate.

<ssl-certificate>/etc/icecast2/bundle.pem</ssl-certificate>

Last Step

Once this is done, you can go to the Centova interface and reload the server, and it will inhale the new settings. You can test them to make sure it worked by going to https://<yourdomain>:8080 and seeing if it loads. If it doesn’t, you’re still broken, but if it does, congratulations, you now have a secure stream on your internet radio station’s business end!

Except that that doesn’t quite do it.

So it’s /usr/local/letsencrypt/letsencrypt-auto renew,

then rebuild your Icecast PEM file, then use your modified setssl script:

/usr/local/centovacast/sbin/setssl letsencrypt <your domain name>

and then after all that, you have to both restart centova, and then stop your Icecast instance completely and restart it before Icecast will use the new certificate.

Now you’re done.

What a fricking ordeal.