devel November 2013

devel@lists.centos.org

14 participants
12 discussions

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

/opt/rh is a directory and not a symbolic link when installing devtoolset
by Dave Johansen 11 Feb '14

11 Feb '14

I just installed devtoolset-1.1-gcc-c++ and devtoolset-1.1-gcc-plugin-devel on a clean install and after doing so /opt/rh was a directory and not a symbolic link to /opt/centos. It was an easy fix, but is there something I can do to help diagnose the cause of the issue so it won't bite other people? Thanks, Dave

2 2

FreeIPA functional testing
by James Hogarth 01 Feb '14

01 Feb '14

Hi all, The initial commit I made (not carried out pull request just yet) does the following: * Installs IPA packages * Does automated basic configuration of server * Verifies kerberos tickets being issued for host/admin user * Tests adding a user (and checks that the initial password is expired plus the change) In the next few days I'm intending to add: * Test adding a service and getting a keytab and certificate for that service * Test adding a host * Test adding DNS zone and records * Test reloading bind (regression test for RHBA-2013-0739) * Test sudo rules configured via IPA * Test deleting all the stuff added above After that I'll issue the pull request... Next stage subsequent to the server tests working would be client side to tests registration against the IPA server itself... Is there anything else that anyone can think of that would be useful to have in the IPA test suite? Cheers, James

1 1

Qt Creator for CentOS
by Dave Johansen 14 Jan '14

14 Jan '14

Is Qt Creator for Qt 4 available for CentOS (either 5 or 6)? I've installed the qt and qt-devel packages on CentOS 6 and I can launch Qt Designer, but is there a version of Qt Creator available? Thanks, Dave

1 1

CentOS-6.4 OpenStack testing cloud images
by Karanbir Singh 08 Jan '14

08 Jan '14

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 ). With some exceptions like isdn support is removed, as is cups and bluetooth since those things make little sense on a cloud instance ( nothing stopping the users from installing them later if they need to ). Also, cloud-init is included. This is based on the 0.7.x stream and based off sources published by Red Hat in their RHEL-Common/ tree. md5sums: ac6c1f683f18ec2742fc620930b6b77a CentOS-6.4-i386-Minimal-OpenStack.image.bz2 ac6c1f683f18ec2742fc620930b6b77a CentOS-6.4-i386-Minimal-OpenStack.image.qcow2.bz2 d0ef1077886714d9808eb21b0d35b64e CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2 853487ac600963da6c00f69be10f11d5 CentOS-6.4-i386-Minimal-OpenStack.image.raw.bz2 dc16f7339c97856514ce35f65196a928 CentOS-6.4-i386-Minimal-OpenStack.image.vpc.bz2 9169abb16ad2b0a0195574fc8c7c6e7a CentOS-6.4-i386-Minimal-VMware.image.vmdk.bz2 1c1ff6ffca8ca7845f49a017f5386961 CentOS-6.4-x86_64-Minimal-OpenStack.image.bz2 1c1ff6ffca8ca7845f49a017f5386961 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2 2d9a25fa573b3c512e97c9d6cea64657 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2c.bz2 f701914d4eafb563b086853cd8e7e79d CentOS-6.4-x86_64-Minimal-OpenStack.image.raw.bz2 8476063151f9163ba37e260e144270e1 CentOS-6.4-x86_64-Minimal-OpenStack.image.vpc.bz2 a68f0bd1328bd67056e07be8501607a0 CentOS-6.4-x86_64-Minimal-VMware.image.vmdk.bz2 sha256sums: 2418f233fabc02074e54f705667ba16e2845883863e5c2e860ffc5b615f1a096 CentOS-6.4-i386-Minimal-OpenStack.image.bz2 2418f233fabc02074e54f705667ba16e2845883863e5c2e860ffc5b615f1a096 CentOS-6.4-i386-Minimal-OpenStack.image.qcow2.bz2 1156a84f18c62e5bb04d82976e6c7aa412c8486de0780e35b42f97697fe06aed CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2 70c9c4f1a44b8ef349ca13da1993c1b9211a1ec72f68b4ddfc85ad21e70e6e97 CentOS-6.4-i386-Minimal-OpenStack.image.raw.bz2 ec1e5ab7508d9139df110e4a5c957c56a4dc6011fc8030cb6e48d3f6a27866ab CentOS-6.4-i386-Minimal-OpenStack.image.vpc.bz2 675c9717b82b71833cb074e76357aa2325d03730d989507110caa0e6d2e4cb5c CentOS-6.4-i386-Minimal-VMware.image.vmdk.bz2 a68e76596568b9e3117f021ba4d1db983b763ef31097b9aa47139927dcbf14bc CentOS-6.4-x86_64-Minimal-OpenStack.image.bz2 a68e76596568b9e3117f021ba4d1db983b763ef31097b9aa47139927dcbf14bc CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2 888da1ac03dd78027421db0629d899187456058a72a6e555d459bcb1d4f20296 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2c.bz2 4626a83e8d0c706d9303874d0e26d2b127983207adb7a64e079e359e6b33a156 CentOS-6.4-x86_64-Minimal-OpenStack.image.raw.bz2 3bd4c91b276e9b4a049fd5ecd32e6e538593331a1298162ffe07e9033eefd903 CentOS-6.4-x86_64-Minimal-OpenStack.image.vpc.bz2 8c70a927d761e99e1529585b43d8dc2e080977b00436ec7038288d542fba6d4c CentOS-6.4-x86_64-Minimal-VMware.image.vmdk.bz2 Note: these images have not been through a regular CentOS QA cycle, and I am requesting people to actually test these in either dev or test environments that run the hypervisor being tested, the cloud controller being tested and provide feedback here to the mailing list. Please clearly indicate what hypervisor was used, what cloud controller and versions of the relevant software. As a baseline the CentOS CI tests ( https://gitorious.org/testautomation/t_functional ) is a good place to start, if you just need tests to run ( although these tests mostly target machine instances, its still a good baseline for these images ). And while you are at it, please feel free to submit cloud, virtualised, instance and image specific tests. The overall aim is to be ready for inclusion of Cloud image release in sync with iso and distro release for next-version ( 6.5 most likely ). Apart from baseline testing, I am also looking for feedback on package manifests included in the images ( should we add something ? should we remove something ? ) and if there is any need / scope for publishing specific role images as well ? ( eg. should we do a LAMP image ? ) Finally, I want to thank Alessandro and Octavian from Cloudbase Solutions for helping get this effort off the ground, and then their patience as I went through the mechanics of automating the build process and getting the images ready. Enjoy! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

5 13

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel November 2013