Re: [ClusterLabs] [ClusterLabs Developers] [HA/ClusterLabs Summit] Key-Signing Party, 2017 Edition

[Jan Pokorný]

On 24/07/17 16:59 +0200, Jan Pokorný wrote:
> On 23/07/17 12:32 +0100, Adam Spiers wrote:
>> Jan Pokorný  wrote:
>>> So, going to attend summit and want your key signed while reciprocally
>>> spreading the web of trust?
>>> Awesome, let's reuse the steps from the last time:
>>> 
>>> Once you have a key pair (and provided that you are using GnuPG),
>>> please run the following sequence:
>>> 
>>>   # figure out the key ID for the identity to be verified;
>>>   # IDENTITY is either your associated email address/your name
>>>   # if only single key ID matches, specific key otherwise
>>>   # (you can use "gpg -K" to select a desired ID at the "sec" line)
>>>   KEY=$(gpg --with-colons 'IDENTITY' | grep '^pub' | cut -d: -f5)
>> 
>> AFAICS this has two problems: it's missing a --list-key option,
> 
> Bummer!  I've been checking the original thread(s) for responses from
> others, but forgot to check my own:
> http://lists.linux-ha.org/pipermail/linux-ha/2015-January/048511.html
> 
> Thanks for spotting (and the public key already sent), Adam.
> 
>> and it doesn't handle multiple matches for 'IDENTITY'.  So to make it
>> choose the newest key if there are several:
>> 
>>read IDENTITY
>>KEY=$(gpg --with-colons --list-key "$IDENTITY" | grep '^pub' |
>>  sort -t: -nr -k6 | head -n1 | cut -d: -f5)
> 
> Good point.  Hopefully affected persons, allegedly heavy users of GPG,
> are capable to adapt on-the-fly anyway :-)
> 
>>>  # export the public key to a file that is suitable for exchange
>>>  gpg --export -a -- $KEY > $KEY
>>> 
>>>  # verify that you have an expected data to share
>>>  gpg --with-fingerprint -- $KEY

Thanks to the attendants and I am sorry for not responding to the ones
with on-the-edge submissions -- there was actually an active one
accepted and I've refreshed the authoritative record about the event
at https://people.redhat.com/jpokorny/keysigning/2017-ha/ accordingly
(see '*2.*' suffixes).

I'd also kindly ask the actual attendants (one person skipped the
event) to do the remaining signing work within the month at latest.
You can just grab the key of the other, already verified party from
the linked source (or the well known key server if present), sign it,
and then (IMHO) preferably send the signed key back to the original
person at one of his/her listed email, again (IMHO) preferably in an
encrypted form.  There are various tools to help with this workflow at
scale, such as PIUS (https://github.com/jaymzh/pius) to give an
example, but YMMV.

May the web of trust be with you.

-- 
Jan (Poki)


pgpEgIhORttyN.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Clusterlabs Summit 2017 is on!

[Jan Pokorný]

On 06/09/17 09:45 +0200, Digimer wrote:
> This is, by far, the largest summit yet. Very stoked!
> 
> Fellow attendees; Feel free to share your pictures!
> 
> https://photos.app.goo.gl/vBeC83yWTZcxRgux1

"Wow!  Such HA.  Very cluster" :)

Side question: is anyone up for the early Friday morning lake swim
challenge?  There's at least two contestants at this point :)

-- 
Jan (Poki)


pgpF3h1iJsMsX.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

[ClusterLabs] DRBD, dual-primary, Live-Migration - Cluster FS necessary ?

[Lentes, Bernd]

Hi,

i just want to be sure. I created a DRBD partition in a dual primary setup. I 
have a VirtualDomain (KVM) resource which resides in the naked DRBD (without 
FS), and i can live migrate.
Are there situations where in this setup a cluster fs is necessary/recommended 
? I'd like to avoid it, it causes more complexity.
Btw: resource level fencing is necessary. Is the setup for dual-primary the 
same as with single-primary ?

My cluster: SLES 11 SP4, DRBD 8.4.4, pacemaker 1.12.

Thanks.


Bernd


-- 
Bernd Lentes 

Systemadministration 
institute of developmental genetics 
Gebäude 35.34 - Raum 208 
HelmholtzZentrum München 
bernd.len...@helmholtz-muenchen.de 
phone: +49 (0)89 3187 1241 
fax: +49 (0)89 3187 2294 

no backup - no mercy
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671


___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

[ClusterLabs] 2017 ClusterLabs Summit -- Pacemaker 1.2.0 or 2.0 talk

[Ken Gaillot]

I thought the first day of the 2017 ClusterLabs Summit went impressively
well today. We had about 50 attendees from Alteeve, Citrix, Debian,
Linbit, Red Hat, SuSE, and possibly more I've missed. The talks were
packed with information and covered a wide variety of topics, from
container orchestration to storage management to GUIs.

I gave a talk on future directions for Pacemaker. The slides are
available at:

   https://www.clusterlabs.org/images/Pacemaker-slides-2017-09-06.pdf

The main idea is that Pacemaker 1.2.0 and/or 2.0 will be more about
removing legacy code more than adding anything new. As the slides are
presented, my original idea was to release 1.2.0 in the near term, with
smaller changes that don't affect rolling upgrades, then 2.0 at some
point further in the future, that would break rolling upgrades for a
(hopefully small) subset of users.

However after discussions during and after the talk, it seems more
worthwhile to go straight to 2.0, with the major change being dropping
support for the legacy cluster layers -- heartbeat, CMAN, and the
corosync 1 pacemaker plugin. This would allow us to simplify the
pacemaker code and make it easier to add new features in the future. We
would keep the 1.1 branch alive for a period of time, and anyone who
still uses the older stacks, but is interested in fixes or features from
the 2.0 line, could submit pull requests to backport them to 1.1.

I'd like to open the discussion on this list as to what changes should
be in 2.0. The slides give some examples that fall into categories:

* Changes in Pacemaker's defaults: a higher default stonith-timeout;
defaulting record-pending to true, which will allow status displays to
show when an action (such as start or stop) is currently in progress;
interpreting a negative stonith-watchdog-timeout as meaning to
automatically calculate a value (the default of 0 would continue to mean
disabling watchdog use by Pacemaker); moving the default location of the
Pacemaker detail log to /var/log/cluster/pacemaker.log (a change from
the slides, based on summit discussions), and removing support for some
very rarely used legacy names for various configuration values.

* Changes in command-line tool behavior: We might drop old legacy
synonyms for command-line options, such as "crm_resource --host-uname"
for what is now "crm_resource --node"; and remove crm_mon's built-in
SNMP/ESMTP support in favor of the relatively recent alerts feature.

* Changes in the C API: This would affect very few people -- only users
who wrote their own C code using the Pacemaker C libraries. We would
coordinate these changes with the handful of public projects (such as
sbd) that use the API. These changes will be discussed further on the
develop...@clusterlabs.org mailing list rather than this one.

* Breaking rolling upgrades for certain legacy features: We would try to
keep the number of affected users to a minimum. Examples are
configurations created under pre-Pacemaker-1.0 and never converted to
the post-1.0 XML syntax; the undocumented "resource isolation" feature,
which has been superseded by the new bundle feature; certain legacy
cluster options that changed names long ago; and as mentioned, support
for the heartbeat, CMAN, and corosync 1+plugin stacks. Also, dropping
support for "legacy attrd" would mean that rolling upgrades from
Pacemaker older than 1.1.11, even if running on corosync 2, would not
work (even then, a rolling upgrade would work in two steps, first to a
later 1.1 version, then to 2.0).

The purpose of this email is to start a discussion about these changes.
Nothing is set in stone. We do want to focus more on removing legacy
usage rather than adding new features in the 2.0 release. Anyone who has
an opinion or questions about the changes mentioned above, or
suggestions for similar changes, is encouraged to participate.

-- 
Ken Gaillot 





___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

[ClusterLabs] Clusterlabs Summit 2017 is on!

[Digimer]

This is, by far, the largest summit yet. Very stoked!

Fellow attendees; Feel free to share your pictures!

https://photos.app.goo.gl/vBeC83yWTZcxRgux1

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org