On Tue, Aug 11, 2015 at 5:46 PM Niall Douglas wrote:

On 11 Aug 2015 at 1:36, Klaim - Joël Lamotte wrote:

...

...

I noticed today that the https of boost.org is expired, and should have a new certificate: https://www.ssllabs.com/ssltest/analyze.html?d=boost.org

My understanding is that the process to renew the certificate was started few months ago but got nowhere. Not totally sure why though. The last status report from the steering committee is available there: http://permalink.gmane.org/gmane.comp.lib.boost.steering/126

We have a new SSL cert, and have had for some months.

The problem is installing it. We no longer have root access to the server in question and I understand the person who had root access isn't responding to email.

Who is this person? I am asking just in case it is someone at Indiana University. If it is someone here, it could be that they moved away and are no longer part of IU.

We would move to new servers, but need root access to copy off all the existing data. So we keep pinging emails, and hope one day the person in question replies.

This is why we need a dedicated employed person to do this stuff, to keep migration plans and plan upkeep so getting orphaned from access never occurs in the first place, and even if it did there is a live offsite backup configured using docker/drbd etc we can replicate from. The steering committee can only authorise that spending if there is consensus from boost-dev that someone should be employed to do this stuff, until that happens this situation will keep recurring into the future with no end in sight.

Niall

-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 12-Aug-15 12:38 AM, Niall Douglas wrote:

On 11 Aug 2015 at 1:36, Klaim - Joël Lamotte wrote:

...

...

I noticed today that the https of boost.org is expired, and should have a new certificate: https://www.ssllabs.com/ssltest/analyze.html?d=boost.org

My understanding is that the process to renew the certificate was started few months ago but got nowhere. Not totally sure why though. The last status report from the steering committee is available there: http://permalink.gmane.org/gmane.comp.lib.boost.steering/126

We have a new SSL cert, and have had for some months.

The problem is installing it. We no longer have root access to the server in question and I understand the person who had root access isn't responding to email.

It's unfortunate that the Steering Committee had not taken a decisive action here - either reaching other people at OSL - or deciding that we've lost webserver access completely, and need to start over.

We would move to new servers, but need root access to copy off all the existing data. So we keep pinging emails, and hope one day the person in question replies.

How about starting a new server, configuring nginx to proxy to the current server by IP address, and changing DNS to point to the new server? SSL will be handled by the new server.

This is why we need a dedicated employed person to do this stuff,to keep migration plans and plan upkeep so getting orphaned from access never occurs in the first place, and even if it did there is a live offsite backup configured using docker/drbd etc we can replicate from. The steering committee can only authorise that spending if there is consensus from boost-dev that someone should be employed to do this stuff, until that happens this situation will keep recurring into the future with no end in sight.

Lots of open-source project manage to have a website without employing anybody. I think the problem is really access, not employment. - Volodya

On 14/08/15 09:33 AM, Glen Fernandes wrote:

What else do we use Trac for now besides bug reporting? Is there a plan to move to something else? (I couldn't find the thread that discussed a move to Github issues).

I think it might be best if such a decision didn't have to be taken for all of Boost at once. Why can't individual project maintainers decide for themselves (and their respective communities) what tools to use ? For example, I'm actively encouraging new Boost.Python issues to be filed on github, and I have documented that in the Boost.Python website (http://boostorg.github.io/python). I find that github makes it easy to set up project-specific websites, issue trackers, and wikis. (The only thing missing are mailing lists.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 8/14/15 6:45 AM, Stefan Seefeld wrote:

On 14/08/15 09:33 AM, Glen Fernandes wrote:

...

What else do we use Trac for now besides bug reporting? Is there a plan to move to something else? (I couldn't find the thread that discussed a move to Github issues).

I think it might be best if such a decision didn't have to be taken for all of Boost at once. Why can't individual project maintainers decide for themselves (and their respective communities) what tools to use ? For example, I'm actively encouraging new Boost.Python issues to be filed on github, and I have documented that in the Boost.Python website (http://boostorg.github.io/python). I find that github makes it easy to set up project-specific websites, issue trackers, and wikis. (The only thing missing are mailing lists.)

This is a natural evolution of the boost modularization effort. In my view their is not reason why all libraries need to use the same issues database. This was one of the proposals which I made at my Boost 2.0 presentation at C++Now. The www.blincubator.com libraries page presents as prototype of how this would work. The library page presents a common facade which has pointer to the library's issues database and other information. Something like this could present a common interface for boost libraries while still permitting library authors to select the most appropriate solution. Robert Ramey PS - slightly off topic - I believe that a more recent version of TRAC can support keeping issues in both githup and the local trac database. So an upgrade here would be very helpful. RR

On 14/08/2015 17:35, Fletcher, John P wrote:

On a related issue, when I started to be a maintainer of Phoenix at the beginning of 2014, I requested a password for Trac to be able to change the status of issues as they were resolved. I followed the requested procedure and never received an answer. This was after the change to github for the files, so I have a password for that.

If there is a new system could we get the password system sorted as well? You should have Trac access now - see other email.

John.

On Fri, Aug 14, 2015 at 2:51 AM Vladimir Prus wrote:

On 12-Aug-15 12:38 AM, Niall Douglas wrote:

...

On 11 Aug 2015 at 1:36, Klaim - Joël Lamotte wrote:

...

...

I noticed today that the https of boost.org is expired, and should have a new certificate: https://www.ssllabs.com/ssltest/analyze.html?d=boost.org

My understanding is that the process to renew the certificate was started few months ago but got nowhere. Not totally sure why though. The last status report from the steering committee is available there: http://permalink.gmane.org/gmane.comp.lib.boost.steering/126

We have a new SSL cert, and have had for some months.

The problem is installing it. We no longer have root access to the server in question and I understand the person who had root access isn't responding to email.

It's unfortunate that the Steering Committee had not taken a decisive action here - either reaching other people at OSL - or deciding that we've lost webserver access completely, and need to start over.

As I said in my previous email, there was an exchange between our admin and boost. The certificate was delivered to us, but it was incomplete, missing the key. We asked for the key, but the email thread broke off, and we never got the necessary files. If someone has all the necessary files, we can get the key installed today. If nobody has the files and we should get the certificate ourselves, we are open to that.

...

We would move to new servers, but need root access to copy off all the existing data. So we keep pinging emails, and hope one day the person in question replies.

How about starting a new server, configuring nginx to proxy to the current server by IP address, and changing DNS to point to the new server? SSL will be handled by the new server.

I suggest that if someone actually has all the necessary files, we can install them directly on the server.

This is why we need a dedicated employed person to do this stuff,to

...

keep migration plans and plan upkeep so getting orphaned from access never occurs in the first place, and even if it did there is a live offsite backup configured using docker/drbd etc we can replicate from. The steering committee can only authorise that spending if there is consensus from boost-dev that someone should be employed to do this stuff, until that happens this situation will keep recurring into the future with no end in sight.

Lots of open-source project manage to have a website without employing anybody. I think the problem is really access, not employment.

Again, we have a full time sys admin that can do whatever is necessary.

- Volodya

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 8/14/15 7:40 AM, Michael Caisse wrote:

I've been one of the 3rd parties with no control, access, or keys that has been trying to nudge all of the in-the-know parties to get something done (via personal emails). We finally got to the point where the admin was responding but then the keys that were purchased were not SHA-2.

We left off with the group that can purchase the SHA-2 wildcard cert needed the admin to provide the CSR to do so.

This is all mind numbingly frustrating. I appreciate the sentiment of finding new hosting and we (Ciere) have already done that for some Boost assets. It also requires a level access to the old system that we don't have. We are actively working on a transition.

Meanwhile ... I'll start emailing again (o;

As "chair" of the meeting held at C++Now which addressed the subject of "Boost Web Presence" evolution and wrote up and posted on the steering committee list the meeting minutes, I would like to ratify the sentiment expressed above. news://gmane.org:119/0C3185AA-935A-4760-A45B-801FC88879DE@rrsd.com You've generously agreed to make available resources of your company to promote this agenda. I would have thought that getting the security certificate updated and trac updated would have been trivial and a good test of our ability to do anything to improve and modernize our web presence. Well, it looks like I'm wrong again. So while waiting for this get to get addressed, let's start moving on. The first step we agreed upon was for you to propose a "road map" about what our web presence should look like so that everyone can spitball it in the usual manner. We won't really reach a strong consensus on everything of course but there may be some ideas which come out of it and perhaps we'll avoid some dumb missteps. This exercise can proceed under a new topic - "boost web presence evolution" on either this list or another list - steering committee or user list. I'm thinking this list would be the best. Then you can proceed to do the work according to the boost "rule" - he who actually takes responsibility for doing the work get's to decide how to do it. Hopefully, by the time any actual work is ready to be launched - we'll have the access we need - if not - we'll find some other way to move forward. Robert Ramey

On 08/13/2015 11:51 PM, Vladimir Prus wrote:

On 12-Aug-15 12:38 AM, Niall Douglas wrote:

...

On 11 Aug 2015 at 1:36, Klaim - Joël Lamotte wrote:

...

We would move to new servers, but need root access to copy off all the existing data. So we keep pinging emails, and hope one day the person in question replies.

How about starting a new server, configuring nginx to proxy to the current server by IP address, and changing DNS to point to the new server? SSL will be handled by the new server.

If this was just the webserver for the website it would be fine, but it is the trac server and that is creating some problems. We *will* have a solution. It will have to involve control in the end.

...

This is why we need a dedicated employed person to do this stuff,to keep migration plans and plan upkeep so getting orphaned from access never occurs in the first place, and even if it did there is a live offsite backup configured using docker/drbd etc we can replicate from. The steering committee can only authorise that spending if there is consensus from boost-dev that someone should be employed to do this stuff, until that happens this situation will keep recurring into the future with no end in sight.

Lots of open-source project manage to have a website without employing anybody. I think the problem is really access, not employment.

Agreed. We just need access. There are many people willing to do the work. michael -- Michael Caisse ciere consulting ciere.com