devel

devel@lists.centos.org

5 participants
4641 discussions

Input for CentOS7
by Joshua Thijssen 19 Dec '13

19 Dec '13

Hi all, As a newcomer on the list with not much time, but enough to hopefully be a bit useful to the upcoming CentOS7 release, i'm wondering what the best action is I could take? I'm seeing lots of things happening here and in other places like CentOS but not sure if is there is something i could focus on or help out? I'm seeing some info at http://seven.centos.org/ about t_functional, but i'm not sure if that is the place where help would be welcome, and if so, how to proceed to be honest. gr, josh

2 3

The Guster issue
by Karanbir Singh 18 Dec '13

18 Dec '13

hi, soliciting comments on http://bugs.centos.org/view.php?id=6820 ( which deals with the partial component inclusion of glusterfs into the base distro ). There are a couple of workarounds mentioned there, but none seem perfect. In an ideal world, it would be nice if Red Hat had their RHS gluster rpms in line with the gluster rpms shipped in the base distro and we could use those into CentOS-Extras. the closest other practical option seems to be building gluster --with server enabled, and shipping the extra rpms into CentOS-Extras; provided the '--with server' is retained going forward, this would atleast mean we have version sync between the client code in the distro and the server code in CentOS Extras. The option of just adding all the gluster code into the distro we ship, server and client content included, seems very intrusive and might have an impact on third party expectations. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 1

Issues with recent firefox update on CentOS 5
by Simon Matter 17 Dec '13

17 Dec '13

Hi, As posted in this bug http://bugs.centos.org/view.php?id=6843 there are now problems with the current firefox on CentOS 5 to shutdown firefox cleanly. If others experience the same please report if you can reproduce it. While we are at it, may it be possible for the developers to rebuild the package with the correct config as shown here: http://bugs.centos.org/view.php?id=6843#bugnotes If it makes no difference then we at least know that it may also happen with upstreams package. Regards and thanks for all the hard work! Simon

3 2

signng the centos.org domain
by Karanbir Singh 10 Dec '13

10 Dec '13

hi, I think we have enough infra in place and can manage it well enough in order to be able to sign the centos.org domain records; is there any reason why we should not look at doing this ? Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 2

a question about rpmbuild command
by wk 04 Dec '13

04 Dec '13

Hi,everyone http://www.redhat.com/archives/shrike-list/2003-April/msg00069.html http://fedoraproject.org/wiki/StackTraces http://old-en.opensuse.org/Packaging/Debuginfo This document said:"passing -g to gcc or g++". And "Note that the default CFLAGS and CXXFLAGS of the distro already contain -g, " My question is : I build souce code a.c with myself gcc/make configfile. first time: compile a.c with -O2,then get a1.bin second time: compile a.c woth -O2 -g,then strip debug symbols.then get a2.bin But i find a2.bin is slower then a1.bin.The performance of a2.bin is 5% slower. Should a2.bin run as fast as a1.bin?(performance is same?)//Tomorrow i will provide the complete commands. Can anyone give some advice? I find that:rpmbuild run gcc one time with -g -O2,then get a.rpm and a.debuginforpm. thanks.

2 1

Installing CentOs without NetFilter
by Robert Clove 04 Dec '13

04 Dec '13

Hi All, Can it be possible to install Centos without installing the Netfilter. Thanks Clove

5 6

AUTO: Jens Neu is out of the office (returning 12/02/2013)
by Jens Neu 25 Nov '13

25 Nov '13

I am out of the office until 12/02/2013. Please contact hss(a)biotronik.com in urgent cases. Note: This is an automated response to your message "Re: [CentOS-devel] CentOS-6.4 OpenStack testing cloud images" sent on 25.11.2013 13:24:03. This is the only notification you will receive while this person is away. www.biotronik.com BIOTRONIK - Celebrating 50 years of excellence Founded in 1963 with the development of the first German pacemaker, BIOTRONIK has brought innovations and the highest quality standards to the cardiac rhythm management and vascular intervention fields in more than 100 countries around the world. We’ve developed advanced technologies such as BIOTRONIK Home Monitoring®, Closed Loop Stimulation (CLS) and Orsiro, the industry's first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio of cardiac devices with ProMRI®, an advanced technology that gives patients access to magnetic resonance (MR) scanning. BIOTRONIK SE & Co. KG Woermannkehre 1, 12359 Berlin, Germany Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 Vertreten durch ihre Komplementärin: BIOTRONIK MT SE Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B Geschäftsführende Direktoren: Christoph Böhmer, Dr. Lothar Krings This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document.

1 0

Re: [CentOS-devel] CentOS-6.4 OpenStack testing cloud images
by Juerg Haefliger 25 Nov '13

25 Nov '13

Hi KB, Sorry for the delayed response, I wasn't subscribed to the devel list. I'm also replying to some of the comments that other users posted. Sorry for messing up the thread. I tested your image in OpenStack Havana with KVM so my comments are very much OpenStack centric. > Hi, > CentOS-6.4 i386 and x86_64 images targetting OpenStack are now available > for testing at http://dev.centos.org/centos/hvm/ Images are available > for KVM, Hyper-V, VMware, Xen and any other HVM hypervisor. Although, > the 6.x kernel has the pv support enabled, so should work fine under > paravirt Xen as well. > Images are published as raw, qcow2 qcow2compressed and vpc ( vhd ) for > both i386 and x86_64 CentOS-6.4 The images represent media versions, and > have not had an update run against them. Its highly recommended that in > testing, please check this version *then* do a yum update and repeat > tests to ensure that there is no test result change in the 6.4+updates > tree's. > Keeping in line with the general CentOS Cloud strategy, ie to help > people migrate or investigate cloud instances, we expect the images to > represent as close as possible to a real machine CentOS install ( ie. no > cloud specific user, people use root to login, selinux is enabled ). I'd prefer a non-root default user to be inline with the other community images. IMHO it's a convenience to not have to create a non-root user after spinning up an instance. But cloud-init will take care of all that for you, if you configure it correctly, which doesn't seem to be the case in your image. I.e., cloud-init creates a 'cloud-user' and disables root login but for some reason the cloud-user is not allowed to sudo (should be handled by cloud-init) so there's no way to gain root permissions. In general, the cloud environment has no business in mocking with a guest image. Yes, OpenStack is still injecting keys but that is likely to change (I believe). It should be up to the instance to configure itself which is what we have cloud-init for. In terms of users, I vote for: - A 'centos' default user without a password (no console login) and password-less sudo permissions. This follows Fedora and Ubuntu and to some degree Debian conventions. IIRC Debinan uses 'admin' as the default user. - Disabled root login and certainly no standard well-known password which is simply a security disaster waiting to happen. I'm not too crazy about SSH password access and cloud-init disables that as well (unless you tell it not to). In general, a cloud image should be as locked-down as possible to reduce the risk of somebody else taking over your instance before you can get to it. Providing SSH key access is the preferred method. Everything else can be enabled later or when the instance is launched (for example by providing a configuration script that cloud-init executes on first boot). Similarly, selinux should be enabled by default. The firewall can be discussed. I think it's not required since the cloud environment already provides that functionality and you have to specifically open ports to get access to your instance. As for console logins, why would we want that in the base image? Can somebody give a use case? I just don't see it as useful. We have SSH access and as mentioned everything else required/desired should be enabled/configured once the instance is up. If SSH access doesn't work after first boot, then there's something fundamentaly broken and console access will most likely not work either. LVM: What's the rational for using LVM? It's not like we can just add another disk to the instance and add it to the volume. IMHO it just adds unnecessary overhead and breaks the growroot functionality. dracut-modules-growroot (which I maintain in EPEL) doesn't support LVM. swap: Providing a swap device in a cloud image is debatable as well. Some clouds charge for IOs and you don't want to pay for swap activity so the cloud images I'm aware of don't have a predefined swap device. Again, it can always be added later if need be. console: As mentioned by others, please add 'console=tty1' to the kernel commandline to get some messages on the virtual console: 'console=tty1 console=ttyS0' (See https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695 for the rational to use tty1 instead of tty0). If you try to make this image as close to regular CentOS as possible, you might confuse other cloud users that are used to certain things in other cloud images. Although those 'things' are not standardized and we're not required to follow them. It's a balancing act, I guess. > CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2 > CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2 Why the bzip2 compression on top of qcow compression? It doesn't create much smaller files and requires and extra step after downloading the images. No big deal, though. > Enjoy! Good work! ...Juerg

1 0

how to configure networking in the "first boot" stage
by jojo 12 Nov '13

12 Nov '13

Hi Sancho, I want to re-config networking in the "first boot" stage, but there are just "welcome", "create user" and so on except "networking", how to add "networking" configuration in the "first boot" stage ? Thanks, - Jojo

1 0

Getting there faster
by Karanbir Singh 10 Nov '13

10 Nov '13

hi Guys One of the key problems we need to solve / resolve and do so with some level of urgency is the mirror problem : How do we get content 'out there' fast enough to reduce the time-to-release lag. Typically, from the time everything is ready to go and the release notes / release email are done, it takes 3 days to get to a releaseable stage for the mirror network. The rsync tree that we are using at this point is clearly not good-enough ( either because of how we use it, or because of what it is and how it works ). Also, release time activity and how donors react to them makes it tricky to rely on specific nodes - something we really need to get to in order to improve the rsync tree cascading setup we have in place. Thoughts, ideas ? Discuss! - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

7 17

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel