Are there any plans for enabling single-sign-on between the different
centos.org subdomains? Perhaps at least between accounts and bugs, if
not also cbs or others?
I remember seeing how SSO can work seamlessly in a big company - the
Windows login and a client cert enabled access to pretty much
everything, from web apps like HR, to different servers, even unlocking
the LAN port you were connected to. This is highly practical when it
works. Then again, I was in R&D (not in IT, which had to configure the
whole thing). :)
Regards,
Laurențiu
Hi,
I'm working on openstack/puppet-ceph module to deploy Ceph Jewel for
OpenStack TripleO and Red Hat Director (OpenStack installers).
I'm very interested to know when I'll be able to download Jewel
packages from SIG on x84_64:
buildlogs.centos.org/centos/7/storage/x86_64/ceph-jewel/ currently
does not contain Ceph packages.
Using ceph.com repositories for us is not optimal as we try to use a
maximum of CentOS supported repositories, like we do for OpenStack.
Thanks,
--
Emilien Macchi
We occasionaly get complaints from users that our official Vagrant
images do not include the VirtualBox Guest Additions. We do not include
them because the CentOS repositories do not have any package for
VirtualBox. Packaging it would probably require a significant amount of
work - the Debian source package shows quite a number of first-level
dependencies, probably not all already available in CentOS. [1] I'm
also not sure if packaging the full VirtualBox is even desirable. [2]
The alternative would be to package just the Guest Additions (which have
considerably fewer build dependencies), to be able to include them in
the Vagrant images. Two VirtualBox developers told me in #vbox-devel
that the source code already supports building just the Guest Additions,
and it's actually used for generating the official download images: one
should simply invoke "kmk VBOX_ONLY_ADDITIONS=1", or, I quote: 'kmk
VBOX_ONLY_ADDITIONS=1 packing to produce the ISO, which will only be for
one platform and bit count.' They also believe we should be able to get
away with simply providing the binary modules, since our kernels have a
stable ABI (the upstream Guest Additions ISO, as well as the Debian
packages, require DKMS and the development tools and kernel headers,
which would considerably increase the size of our Vagrant images). We
would probably need to incorporate some functionality from their
installer at RPM build time, to get just the binary modules.
Regards,
Laurențiu
[1] https://packages.debian.org/sid/virtualbox
[2] https://lkml.org/lkml/2011/10/6/317
Hello Folks,
Please note that next week on Monday cbs.centos.org will be upgraded to
support newer features.
What does that mean for you ?
Next Monday, we will upgrade imagefactory to latest version.
The change is scheduled to be implemented on Monday August 22nd 7:00 am
UTC time
You can convert to local time with $(date -d '2016-08-22 7:00 UTC')
What will be the impact ?
During the update it will not be possible to build packages or images.
Please note that temporary repositories served on cbs.centos.org will be
available (Mostly used for CI).
Please let us know before Thursday August 18th if it could impact
dramatically your work/releases schedule.
--
Thomas Oulevey on behalf of the infrastructure team
A question came up on the OpenShift-Ansible issue[1], that I would
like to discuss with a broader, CentOS based community.
"With OpenShift Origin, running yum update or yum upgrade will include
any updated OpenShift packages, potentially causing issues."
With Origin 1.3 getting ready for release candidate, this is a very
valid concern.
I've already put this on the next PaaS SIG meeting agenda, but I
wouldn't mind hearing opinions before the meeting. Feel free to state
problems, worries, solutions, or overall comments by replying to this
email and/or adding to the issue.
Thank You
Troy
[1] - https://github.com/openshift/openshift-ansible/issues/2293
Security updates for the sclo-ror42 software collection, which provides
Ruby on Rails 4.2, are now available in the CentOS SCLo SIG testing
repository.
To apply the updates:
yum upgrade --enablerepo=centos-sclo-sclo-testing --nogpgcheck sclo-ror42\*
These fix:
a) CVE-2016-6316: Possible XSS Vulnerability in Action View
https://groups.google.com/forum/#!topic/ruby-security-ann/8B2iV2tPRSE
b) CVE-2016-6317: Unsafe Query Generation Risk in Active Record
https://groups.google.com/forum/#!topic/ruby-security-ann/WccgKSKiPZA
The packages updated are (both el6/7):
sclo-ror42-rubygem-actionpack-4.2.5.1-2.el7
sclo-ror42-rubygem-activerecord-4.2.5.1-3.el7
sclo-ror42-rubygem-actionview-4.2.5.1-3.el7
I'll push them to stable in a week or so's time, but would appreciate
any feedback.
--
Dominic Cleal
dominic(a)cleal.org
Thanks to the work of François Cami, we now have a build of Ceph's Jewel
release available for testing on the AArch64 platform.
You can find the packages on buildlogs at
http://buildlogs.centos.org/centos/7/storage/aarch64/ceph-jewel/
To install them via yum, simply add a repository definition like the one
below:
cat /etc/yum.repos.d/ceph-jewel-testing.repo
[ceph-jewel-testing]
name=Ceph Jewel Testing
baseurl=http://buildlogs.centos.org/centos/7/storage/aarch64/ceph-jewel/
metadata_expire=6h
gpgcheck=0
Please test them out and let us know if anything isn't behaving as you'd
expect.
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
Hi,
so for people who do not know me, my name is Michael Scherer, I work as
a sysadmin on the open source and standard (OSAS) team at Red Hat,
focusing on infrastructure issues for community my employer want to
support (in the limit of 26h per day). In practice, that mean doing
system administration for projects like manageiq, ovirt, gluster and
others.
My team want to push for community owned infrastructure (kinda like what
Fedora and Mageia do, leveraging the config as code pattern and solution
like puppet and ansible), so we are publishing as much as possible our
configuration under free software license and so we have started to
develop a set of ansible roles that can be reused accross community,
trying to provides best practices[1]. They are partially on gitlab.com
and partially on github.com.
We standardized on ansible for various reasons, mostly due to a
perceived higher ease of use by beginners and a slightly less painful
deployment model (no need to keep agent and server in sync, which was a
pain point for me for puppet, despites loving puppet itself).
And we reached the conclusion that we could make this work useful to
others, and a logical conclusion was to join the config management sig.
So what we had in mind is the following:
- we could use the roles to test them on various centos platforms with
Centos CI and thus providing easy to use roles for centos users. We are
mostly using Centos for infastructure.
- the roles could also be used to test against the git head version of
ansible to make sure that regression in role and/or ansible are detected
early
- this could show as best practices for roles developpers, with testing,
etc
So, what does members of the SIG think of the idea ?
[1] who are highly opinionated and subjective, as I said, I am sysadmin,
which is a polite way to say I am professionally stubborn.
--
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS
Hello,
It's time for our weekly PaaS SIG sync-up meeting
Time: 1700 UTC - Wedensdays
Date: Today Wedensday, 10 August 2016
Where: IRC- Freenode - #centos-devel
Agenda:
- OpenShift Current Status
-- rpms
-- Documentation
-- Automated testing
-- images / image building
- Open Floor
Minutes from last meeting:
https://www.centos.org/minutes/2016/august/centos-devel.2016-08-03-17.00.lo…