Re: Running CLI uitilities not available in Fedora?

[Ryan S. Brown]

On 03/02/2016 06:50 AM, Peter Lemenkov wrote:

Hello All!
I'd like to ask you for advice. I've packaged an application which can
use external CLI tools (not available in Fedora for various non-legal
reasons). Shall I remove support for these tools or better keep it?


The answer is "it depends".

I don't think removing support/features from tools you package is the 
way forward: it makes maintenance harder for you, and if users install 
the non-available CLI then try to use your packaged program, they would 
be surprised to find it can't use that external CLI tool.


Definitely make sure that your packaged app has a useful error when 
users try to use features that require the external CLI, and maybe even 
tells them where to find it if they're willing to install from external 
sources.


-Ryan

--
Ryan Brown / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ryan S. Brown]

On 02/22/2016 05:34 PM, Stephen John Smoogen wrote:

On 22 February 2016 at 13:00, Ralf Senderek  wrote:



The Fedora team could get a profile and verify the key(s) through
github, the Fedora and Red Hat web sites, the Fedora magazine twitter
account, and by having the Fedora team all sign publicly.


Every little helps. The important step would be if the Fedora devs state the
fingerprints in a visible way that risks their good reputation if the 
information
turned out to be incorrect. These statements would then be the foundation of
trust in what the Fedora 24 key signs.



OK and how many people check to see what another person's reputation
is? And how many people have had gotten bad reputations from signing
bad things? It all sounds great on paper, but without actual methods
and regular checks.. it is as useless as a keysigning party where no
one does a full check of the passport and driver's license with the
issueing authority. [We all do the $200.00 background check on
everyone we sign don't we?]


I don't, but I think there's benefit in using keybase.io and having any 
Fedora contributors verify that, because:


1. Keybase is easy to check - pop open the web page and it's all there
2. Hosted outside Fedora infrastructure, so 2 points of compromise would 
have to happen



Also, keep in mind that the checks on keybase aren't necessarily "you 
are Ryan Scott Brown, as identified by driver's license," but rather 
that I am the @ryan_sb on twitter, and ryansb on github, and owner of 
rsb.io. For most "people on the internet" the second set of parameters 
is what people actually know me as, so that's more useful for the looser 
verification of "someone I think would notice if Fedora switched their 
GPG key"


Also, tying the GPG key to the various Fedora project social accounts 
would help since, again, that's another point of compromise that would 
need to happen to switch up our .iso's.


Literally nothing we can ever do will be bulletproof[1], but doing 
anything better than putting the GPG keys on the same site as the ISOs 
isn't futile.



1: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf


Combined with having the key on getfedora.org, it at least provides a
measure of protection against our site being compromised. It also has
the benefit of, if someone knows of any Fedora devs on Twitter or
another service, they can follow the web of social-service trust. This
isn't as good as if they had a direct path to the Fedora WoT through
normal signatures, but it's much more likely to actually occur.


Yes all of this, please.


--
Ryan Brown / Senior Software Engineer, OpenStack / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ryan S. Brown]

On 02/22/2016 02:22 PM, Ralf Senderek wrote:



If the site is compromised, most bets are off sadly.


Yes, for people who look only in one place, the manipulated web server.
But that is the reason why the fingerprint has to pop up in different places
where it is hard to fake. Even if this one user can be tricked, others can
discover that the site is compromised if the fingerprint is independently 
recorded
many times elsewhere.

BTW, pointing to a key server is not the way to convince anyone. A key server
is a convenient way to get keys, not a tool to assure their authenticity.
So I don't think that there is much of an alternative other than someone 
stepping in
and provide some first-hand knowledge about the key.


Could an external service such as keybase.io be helpful here? It's not a 
FOSS service, but it's been doing good work on making GPG more 
accessible by tying into many services and putting them all in a sort of 
verification dashboard.


If keybase is new to you, here's my profile https://keybase.io/ryansb

The Fedora team could get a profile and verify the key(s) through 
github, the Fedora and Red Hat web sites, the Fedora magazine twitter 
account, and by having the Fedora team all sign publicly.


Combined with having the key on getfedora.org, it at least provides a 
measure of protection against our site being compromised. It also has 
the benefit of, if someone knows of any Fedora devs on Twitter or 
another service, they can follow the web of social-service trust. This 
isn't as good as if they had a direct path to the Fedora WoT through 
normal signatures, but it's much more likely to actually occur.


--
Ryan Brown / Senior Software Engineer, OpenStack / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ansible in Fedora 23+ (python3)

[Ryan S. Brown]

On 10/15/2015 03:30 PM, Lars Kellogg-Stedman wrote:

On Thu, Oct 15, 2015 at 11:54:29AM -0400, Bill Nottingham wrote:

same python version as the Ansible version you're using.  If Ansible were to
use python3, all module bindings would need to be python 3, and *all the
managed machines would need to have python3 installed*.


Isn't it entirely possible -- through liberal use of 'six' and 'from
future...' -- to write code that will operate correctly with both
Python 2 and Python 3?  I thought that, e.g., OpenStack was pursuing
exactly that strategy.

Sure, you still need your target Python 3 environment to have the
appropriate supporting modules, but that seems like a different issue.
Environments runnning Python 2 should continue to Just Work.


[not an ansible dev, but I am an OpenStack contributor]

The difference here is the span of versions that need to be supported. 
OpenStack is only trying to support 2.7-3.X and the gulf between 2.4 and 
2.7 is actually quite broad. It is likely possible, but it will be a 
very large amount of work and would add dependencies to both runtimes.



Because "no setup" is such a huge part of what makes ansible attractive, 
I doubt adding that dependency would be viable.


--
Ryan Brown / Senior Software Engineer, OpenStack / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gpg keys of older/newer fedora versions

[Ryan S. Brown]

On 08/01/2015 03:25 PM, Zbigniew Jędrzejewski-Szmek wrote:
 On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote:
 On Fri, 17 Jul 2015 17:28:48 +
 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote:

 [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383]

 'dnf install --installroot=... --releasever=XX dnf' can be used to
 bootstrap a Fedora chroot. The only snag is that --nogpg is often
 recommended, because fedora-repos only provides the GPG keys for the
 current and next release.

 It would be convenient (and safe!) to provide keys for past and
 future releases, so such bootstrapping can be done without either
 importing the keys manually and/or using --nogpg.

 I thought I'd ask here first: is there a strong reason *not* to
 include those keys?

 So, I missed this thread, but saw it from the bug filed:

 https://bugzilla.redhat.com/show_bug.cgi?id=1246701

 Several things here:

 * If we ship gpg keys for old eol Fedora releases, aren't we
   encouraging people to setup things we no longer support?
 I never asked for keys from EOL releases. I think keys should
 be removed after EOL.
 
 * If we only ship supported releases in each fedora-repos package, it
   means more churn for that package for everyone as when a release goes
   EOL we would need to push a new update that removes the old EOL key. 
 Is everyone the users or they maintainers of fedora-repos.rpm?
 The churn is really tiny: the package is small, and this happens
 only twice a year, so I dont' think users will notice or care. As for
 the maintainers: I know it is a bit of extra work. I'm trying to ask
 nicely :)
 
 * As till pointed out, mock seems to already carry these keys, so some
   coordination here seems like a good idea no matter what we do. ;) 
 Yeah. One issue I see is that mock seems to be always trailing with
 the updates. Mock in F22 now has
 /etc/pki/mock/RPM-GPG-KEY-fedora-19-primary
 /etc/pki/mock/RPM-GPG-KEY-fedora-19-secondary
 /etc/pki/mock/RPM-GPG-KEY-fedora-20-primary
 /etc/pki/mock/RPM-GPG-KEY-fedora-20-secondary
 /etc/pki/mock/RPM-GPG-KEY-fedora-21-primary
 /etc/pki/mock/RPM-GPG-KEY-fedora-21-secondary
 /etc/pki/mock/RPM-GPG-KEY-fedora-22-primary
 /etc/pki/mock/RPM-GPG-KEY-fedora-22-secondary
 The version in updates-testing removes keys for F19 and F20,
 and adds keys for F23. It has chroot definitions to match those keys.
 *If* mock was relying on fedora-repos to carry they keys, it would
 be possible to have chroots without a matching key. I don't
 know if that would be good (EOL chroots stop working as expected) or
 bad (EOL chroots stop working unexpectedly).

I disagree that including the keys for EOL'd releases counts as
encouraging people to use old stuff. If someone has a reason to be
building RPMs for something way-old, I think it'd be nice for us to keep
those GPG keys available for them.

Speaking only for myself, whenever I have to build something for a very
old box, the last thing I want is mock giving me grief about not having
a GPG key that old.

 * Can you describe the use case here a bit more? Why wouldn't you use
   mock (which has the keys already) to make a chroot? 
 I want to use dnf to create containers, e.g. for running with
 systemd-nspawn. Sometimes for installation of Fedora on a disk
 to bootstrap a new machine. In either way, it is a one-time
 operation where the result is permanent.
 
 mock is about repeatedly creating chroots tailored for rpm building...
 The underlying installation mechanism is pretty much the same,
 but that's about it.
 
 Zbyszek
 

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Ryan S. Brown]

On 06/01/2015 10:37 AM, Tomas Hozza wrote:
 On 06/01/2015 03:32 PM, Matthew Miller wrote:
 On Mon, Jun 01, 2015 at 08:03:27AM -0400, Jan Kurik wrote:
 People use Fedora on portable/mobile devices which are connected to
 diverse networks as and when required. The automatic DNS
 configurations provided by these networks are never trustworthy for
 DNSSEC validation. As currently there is no way to establish such
 trust.
 Is this proposal meant to apply to Cloud and Server as well? With
 Cloud, it's at least conventional to assume that the network
 infrastructure provided by the provider is trustworthy (see
 cloud-init). And Server presumably will not be running on
 portable/mobile devices connecting to arbitrary networks. For Server,
 there may be other advantages, but do we also want these for Cloud?
 As you can read in the Change proposal, this is part of the scope:
 discuss with WGs in which products the change makes sense and
 what are the expectations of WGs for different Fedora products
 
 Yes, we think the change makes sense for Server. It is still
 beneficial from the security point of view to do the DNSSEC
 validation on Server. Even though the configuration on Server
 will be static, dnssec-trigger + unbound can be used for this.
 Otherwise it would require manual configuration from the
 administrator, to enable DNSSEC validation.

I disagree; for server  cloud deployments it doesn't make sense to
duplicate a DNS server on *every* host, and if you care about DNSSEC you
likely already run a trusted resolver.

The trust and management models for Server are fundamentally different
from those of Workstation, since servers don't usually get tossed in a
backpack and put on potentially-hostile coffee shop wi-fi. They also
generally try to run fewer services than a workstation. The datacenter
network is generally trusted, and a shared DNSSEC resolver makes way
more sense.

It may be beneficial from a security PoV to have DNSSEC resolution,
but it isn't beneficial to have to patch 1 million copies of unbound if
a vuln is discovered instead of just a few shared resolvers for the
whole DC.

 ...[snip]...

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Ryan S. Brown]

On 06/01/2015 01:55 PM, Jason L Tibbitts III wrote:
 RSB == Ryan S Brown rya...@redhat.com writes:
 
 RSB I disagree; for server  cloud deployments it doesn't make sense to
 RSB duplicate a DNS server on *every* host, and if you care about
 RSB DNSSEC you likely already run a trusted resolver.
 
 I disagree generally in the case of server deployments.
 
 Having a local caching resolver is pretty much essential, even though we
 all know it's just a workaround for glibc.
 
 Basically, if you have properly functioning DNS on multiple local
 servers but not having anything fancier like heartbeat-based IP handoff
 or a load balancing appliance or something, and the first resolver in
 resolv.conf goes offline, your hosts are screwed.  glibc's resolver code
 is simply horrible.  This is completely exclusive of DNSSEC issues.

I don't think it's essential for either the server or the cloud product.
Servers run in a much more reliable network than your average SOHO or
coffee shop setup, and their behavior with regard to DNS doesn't need a
local caching resolver. LAN DNS (probably with split horizon for
DC-internal services) is plenty fast and reliable, there isn't a need to
run a zillion instances of Unbound.

Also, I've run redundant LAN DNS servers in fairly large deployments,
and ns1 going down certainly hasn't screwed my hosts.

 Of course, most folks who have enough infrastructure to have their own
 DNS servers and such can easily figure out how to configure a local
 resolver if need be, so what's in the default setup really makes no
 difference.  And for the home user who might want to grab the server
 spin/product/whatever-we're-calling-it-this-week, well, I'd think they'd
 want the local resolver. 

I don't think so -- when I pull a fresh server image I expect there to
be very little running on it.

A local DNS resolver would certainly be a surprise to me. Again, this
comes back to the expectation that a server isn't hopping networks or
running somewhere un-trusted where there's a high risk of bad actors.

 What really concerns me is what happens with split DNS.  I assume I'll
 just need to configure the local resolvers to talk only to my resolvers,
 but this would really need to be documented.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: MongoDB Security Defaults

[Ryan S. Brown]

On 02/16/2015 06:56 AM, Marek Skalický wrote:
 Hello,
 this change was in version 2.6.6-4.
 
 I were cleaning config files, adding new options,... I didn't want to
 change any default configuration.

Ah, makes sense. That mongod documentation is ripe for misinterpretation.

 So bind_ip change isn't intended. I wrongly understood this mongod
 comment:
 --bind_ip arg comma separated list of ip addresses to listen on
- all local ips by default
 
 Thanks for reporting. I've fixed it and there should be upgrade to
 version 2.6.7-4 ASAP
 https://koji.fedoraproject.org/koji/taskinfo?taskID=8949655
 https://koji.fedoraproject.org/koji/taskinfo?taskID=8949651

Thanks for fixing this so quickly, much appreciated.

 Marek
 
 Ryan S. Brown píše v Pá 13. 02. 2015 v 08:26 -0500:
 Hello,

 After reading this article[1] on how many totally unsecured mongodb
 installations there are on the internet, I noticed a recent (and
 worrying) change in the defaults on Fedora's mongodb package.

 In January, the Fedora rawhide package for mongo[2] was changed to
 listen on all interfaces by default, but I haven't been able to find any
 information about why it was changed. To help protect users, I think the
 default should be changed back to localhost only. Operators can change
 this setting post-install if needed, hopefully after assessing how risky
 it is to have an open-world database.

 This change could probably be reverted safely as-is, since (I hope)
 nobody is running production mongo clusters on rawhide.

 Debian and Ubuntu have mongodb set to (by default) only listen on
 localhost[3], which is sane and normal for a database that does *no
 authentication of any kind* by default. The same has been true of
 MongoDB Inc.'s[4] example config since approximately 2013[5].


 [1]: http://thehackernews.com/2015/02/mongodb-database-hacking.html
 [2]:
 http://pkgs.fedoraproject.org/cgit/mongodb.git/tree/mongodb.conf?id=be37804b64d9a9b8e8f305d5a89a9c477deac619
 [3]:
 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/mongodb/utopic/view/head:/debian/mongodb.conf
 [4]: https://github.com/mongodb/mongo/blob/master/rpm/mongod.conf
 [5]:
 https://github.com/mongodb/mongo/commit/f8699f77f90ff9b24d23729644ee7cd7ed0e9600

 -- 
 Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
 
 

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

MongoDB Security Defaults

[Ryan S. Brown]

Hello,

After reading this article[1] on how many totally unsecured mongodb
installations there are on the internet, I noticed a recent (and
worrying) change in the defaults on Fedora's mongodb package.

In January, the Fedora rawhide package for mongo[2] was changed to
listen on all interfaces by default, but I haven't been able to find any
information about why it was changed. To help protect users, I think the
default should be changed back to localhost only. Operators can change
this setting post-install if needed, hopefully after assessing how risky
it is to have an open-world database.

This change could probably be reverted safely as-is, since (I hope)
nobody is running production mongo clusters on rawhide.

Debian and Ubuntu have mongodb set to (by default) only listen on
localhost[3], which is sane and normal for a database that does *no
authentication of any kind* by default. The same has been true of
MongoDB Inc.'s[4] example config since approximately 2013[5].


[1]: http://thehackernews.com/2015/02/mongodb-database-hacking.html
[2]:
http://pkgs.fedoraproject.org/cgit/mongodb.git/tree/mongodb.conf?id=be37804b64d9a9b8e8f305d5a89a9c477deac619
[3]:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/mongodb/utopic/view/head:/debian/mongodb.conf
[4]: https://github.com/mongodb/mongo/blob/master/rpm/mongod.conf
[5]:
https://github.com/mongodb/mongo/commit/f8699f77f90ff9b24d23729644ee7cd7ed0e9600

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: MongoDB Security Defaults

[Ryan S. Brown]

On 02/13/2015 11:25 AM, Frank Ch. Eigler wrote:
 Ryan S. Brown rya...@redhat.com writes:
 
 [...]  In January, the Fedora rawhide package for mongo[2] was
 changed to listen on all interfaces by default [...]  To help
 protect users, I think the default should be changed back to
 localhost only. [...]
 
 We have a slew of network-servers in the fedora distribution.
 Apprx. none of them are supposed to be turned on just by virtue of rpm
 installation (so, require an explicit systemctl enable), and apprx.
 none of them get through the system-default firewalld setup.  The
 out-of-the-box risk is therefore nil.

As far as the firewall setup: if they wouldn't get through the firewall,
then there's already extra configuration for operators that want to make
it available to everyone. Why not also have it listen by default on
localhost as an additional safety measure. Especially since *that's how
it is in all current releases*. There's no benefit to moving away from
the (sane) default of localhost-only.

 If you'd like to pursue a distro-wide change for this
 interface-binding level of security, please consider pursuing it via a
 Fedora Change type process rather than piecemeal package-by-package.

I didn't consider this as a distro-wide change, I'll look at the
existing policies and see if there are any that cover this.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Changing default configuration

[Ryan S. Brown]

On 02/10/2015 09:16 AM, Alberto Ruiz wrote:
 On Tue, 2015-02-10 at 14:38 +0100, Marek Skalický wrote:
 Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500:
 On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote:
 does someone know what are Fedora Guidelines (or something similar)
 saying about this bug
 https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ?
 Is is possible to change default configuration file depending on
 available free space?

 Generally, making such a decision at install time is bad, because that
 might not reflect _runtime_. For example, in the cloud image, we use a
 / filesystem as small as Anaconda will allow, but that grows to fill
 available storage when the image is booted.

 Is there a way to make this decision when mongodb runs?


 It should be possible to code this into sysv init script. But I am not
 sure if it is possible to do the same in systemd service...?

 My question was also about whether this should be done by mongoDB? Or
 there should be default configuration and user can easily change it in
 configuration file?
 
 It should be done by MongoDB, I would get in touch with the upstream and
 discuss the problem with them.
 
 Marek

I don't think there should be run- *or* install-time determination on
this. Smallfiles is used for more than just free space reasons and only
the end operator knows whether they need it or not. There's a documented
upstream default, and it's the operator's job to change it if they need to.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Ruby 2.2 landed in Rawhide

[Ryan S. Brown]

On 01/21/2015 03:17 AM, Vít Ondruch wrote:
 Dne 20.1.2015 v 17:44 Jason Rist napsal(a):
 On 01/20/2015 08:01 AM, Vít Ondruch wrote:
 Hi everybody,

 Just heads up that Ruby 2.2 landed in Rawhide. We tried to rebuild every
 package which depends on ruby-devel and libruby.so so most of you should
 be fine already. Nevertheless, there are still some packages remaining,
 usually due to other issues then Ruby. Namely, it is (if I have not
 forget anything):

 hub
 rubygem-openssl_cms
 subversion
 swig
 uwsgi
 vim

 Please let me know if you need any assistance with fixing Ruby related
 build issues of your packages.

 Vít

 Isn't hub Go based now?

 -J
 Not the one in Fedora, not sure about the upstream though 
 Vít
 

Hub upstream[1] is now Go, but the latest release is still ruby. Right
now there's a release candidate for the go version (2.2-rc1) so we
should expect to get that in rawhide soonish.

[1]: https://github.com/github/hub/releases

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Django-1.7 for Fedora 21

[Ryan S. Brown]

On 10/16/2014 09:32 AM, Stephen Gallagher wrote:
 snip
 
 There are no Django applications that are part of the install sets of
 any of the Products or Spins so far as I am aware, so the risk to the
 Project deliverable dates would be minimal. I'd suggest bringing it to
 FESCo for a more complete risk-analysis, but I'd argue that we'd be
 better off shipping python-django as 1.7 and also the python-django16
 package in Fedora 21.
 

+1

Shipping F21 with Django 1.6 as the default will *definitely* have us
kicking ourselves in 6 months. And shipping 1.7 by default will make
lots of Django users/devs happy.

Definitely bring it up to FESCo, but it's probably riskier to be
shipping something that will become unsupported within the release
lifetime than to upgrade to the newer version.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Ryan Brown

[Ryan S. Brown]

Hello all,

My name is Ryan Brown. I'm a long-time user of Fedora and have recently 
begun contributing to Openstack Heat. Heat is [1] a system for 
describing and reproducing infrastructure in Openstack, roughly 
equivalent to AWS CloudFormation.


I'm not yet in the packagers group, but I will be helping maintain the 
Fedora packages for Heat and heat-client.


I can be found in #heat or #rit-foss on freenode (Nick:ryansb).

Cheers,
Ryan


[1]: https://wiki.openstack.org/wiki/Heat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct