similar to: More about my SSL certificate problem

Am Montag, den 15.06.2015, 07:38 -0400 schrieb Steve Matzura: > If I could remove this message from this list, I would! I just figured > out what my problem was, and it's something I thought *FOR SURE* I had > fixed. I've looked at this thing so many times, I fell into the trap > of not seeing the forest for the trees. I had inadvertently omitted > the '<' before

On Mon, Jun 15, 2015 at 07:38:26AM -0400, Steve Matzura wrote: > If I could remove this message from this list, I would! I just figured > out what my problem was, and it's something I thought *FOR SURE* I had > fixed. I've looked at this thing so many times, I fell into the trap > of not seeing the forest for the trees. I had inadvertently omitted > the '<' before

What is the reasoning behind that `<' anyway? It just appears so odd that a path should have that at its front. On Mon, 15 Jun 2015 15:20:25 +0200, you wrote: >Am Montag, den 15.06.2015, 07:38 -0400 schrieb Steve Matzura: >> If I could remove this message from this list, I would! I just figured >> out what my problem was, and it's something I thought *FOR SURE* I had

I wrote that. A missing `<' in front of the path to the main certificate file. On Mon, 15 Jun 2015 13:44:39 +0200, you wrote: >On Mon, Jun 15, 2015 at 07:38:26AM -0400, Steve Matzura wrote: >> If I could remove this message from this list, I would! I just figured >> out what my problem was, and it's something I thought *FOR SURE* I had >> fixed. I've looked at

Looks like a lot of tedium. I'll give it a go on Red Hat, but not before a full backup first. On Wed, 7 Jan 2015 11:26:13 -0800, you wrote: >Hello, > >Fedora and CentOS don't have any prebuilt packages in the standard repos. > >Here are a few guides from the Liquidsoap community, specific to CentOS. >http://puck.in/2013/12/install-liquidsoap-1-1-on-centos-6-4/

Looks like it's what I need. Do you know, is there a distro or repo for Fedora? Or should I build it from source? On Wed, 7 Jan 2015 07:56:39 -0800, you wrote: >Hi Steve. > >Liquidsoap supports CUE sheets as an input. > >http://savonet.sourceforge.net/doc-svn/playlist_parsers.html >On Jan 7, 2015 5:04 AM, "Steve Matzura" <sm at noisynotes.com> wrote: >

On Mon, Jun 15, 2015 at 09:32:39AM -0400, Steve Matzura wrote: > What is the reasoning behind that `<' anyway? It just appears so odd > that a path should have that at its front. I would guess: - make it clearer it's a file and not a string - follow similar syntax as input redirection in sh/perl/.. B

I may have asked this before, but either I didn't, or I've inadvertently discarded the message containing the answer, so pardon please if this is a repeat. Wil EZStream ever support cue sheets--a companion file containing metadata information normally inserted into the stream from that contained in the multimedia file itself? More play-out software is including the ability to produce

I could, but I have this big old Fedora system just waiting for me to get LS working on it, so I think I need to concentrate on making that happen. If it's hard, difficult, tedious, inconvenient, then that's what it is. I want the cue sheet capability some way somehow, so I'm just going to have to knuckle down and buckle down and do it. Right? On Wed, 7 Jan 2015 17:21:27 -0800, you

The public cert part is good, but the private one begins with "Begin private key", not "RSA key." On Sun, 14 Jun 2015 15:54:23 +0200, you wrote: >Am 13.06.2015 um 22:11 schrieb Steve Matzura: >> On Sat, 13 Jun 2015 21:57:06 +0200, you wrote: >> >>> On Sat, Jun 13, 2015 at 03:41:26PM -0400, Steve Matzura wrote: >>>>>>>> Trying

On Sat, 13 Jun 2015 21:57:06 +0200, you wrote: >On Sat, Jun 13, 2015 at 03:41:26PM -0400, Steve Matzura wrote: >> >> > > Trying ::1... # this is certainly suspect >> >> > > Escape character is '^['. >> >> > > Connection closed by foreign host. > >This means the daemon is listening but errors out before able to process.

If I could remove this message from this list, I would! I just figured out what my problem was, and it's something I thought *FOR SURE* I had fixed. I've looked at this thing so many times, I fell into the trap of not seeing the forest for the trees. I had inadvertently omitted the '<' before the first certificate definition. I guess there really is something to the technique of

Am Montag, den 15.06.2015, 13:33 -0400 schrieb Steve Matzura: > I think I have it now! Found info about *correctly* defining > namespaces. I now get the following when telnetting in, and it all > looks valid. > > Trying 127.0.0.1... > Connected to 127.0.0.1. > Escape character is '^]'. > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE >

I made a special pair of keys just for Icecast with this command: $ openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem I combined the two files like this: $ cat cert.pem key.pem > icecast.pem I placed icecast.pem in /etc/icecast2 and used 'chown icecast2:icecast icecast.pem' to change owner to icecast2:icecast. I also changed its protection to

On Mon, 15 Jun 2015 17:22:13 +0200, you wrote: >> Now, when I telnet 127.0.0.1 143 and attempt to log in with the >> string: >> >> a login <any username> <any password> >> >> whether it's one in my users file or not, I get: >> >> a NO [AUTHENTICATIONFAILED] Authentication failed. >> > >Logs might give you a clue what

On Fri, Mar 3, 2017 at 9:55 AM, Hadley Wickham <h.wickham at gmail.com> wrote: >> But, how you propose a warning-to-error transition should be made >> without wreaking havoc? Just flip the switch in R-devel and see CRAN >> and Bioconductor packages break overnight? Particularly Bioconductor >> devel might become non-functional (since at times it requires >>

On 31 Jul 2024, at 0:05, Steve Matzura wrote: > I tried everything, including changing the name of the new PEM containing the properly concatenated certificates as specified in the Icecast configuration. The reload command did not, does not appear to, re-read the certificate file even though the filename has been changed. To make it work, I had to restart the Icecast server in the usual

Is there really a need for these complications? Packages emitting this warning are broken by definition and should be fixed. Perhaps we could "flip the switch" in a test environment and see how much havoc is wreaked and whether authors are sufficiently responsive? Michael On Sat, Mar 4, 2017 at 12:04 PM, Martin Maechler <maechler at stat.math.ethz.ch > wrote: >

On Sat, 13 Jun 2015 20:41:01 +0200, you wrote: >Am Samstag, den 13.06.2015, 13:40 -0400 schrieb Steve Matzura: >> On Sat, 13 Jun 2015 14:16:30 +0200, you wrote: >> >> > Am Samstag, den 13.06.2015, 08:00 -0400 schrieb Steve Matzura: >> > > >> > > All of the above specified settings are correct. Yet, when I >> > > telnet >> >

I tried everything, including changing the name of the new PEM containing the properly concatenated certificates as specified in the Icecast configuration. The reload command did not, does not appear to, re-read the certificate file even though the filename has been changed. To make it work, I had to restart the Icecast server in the usual manner. Is this a bug or is it by design?