devel

devel@lists.centos.org

10 participants
4617 discussions

Storage SIG Meeting minutes (OpenAFS only)
by Andrew Deason 01 Oct '14

01 Oct '14

Here are my notes from the Storage SIG Meeting from 01 Oct 2014, just for the OpenAFS parts. There were some communication difficulties near the end of the meeting, but what I gathered is that I/Jonathan/Ross would handle the minutes for the OpenAFS section, and Lalatendu would write up notes for the rest. Karanbir was distracted or absent for the last few points, I believe. There were a few sections where I had trouble hearing/understanding, so it is entirely possible some of the information here is wrong. But this is what I could remember and understand. Attending: Andrew Deason Jonathan Billings Karanbir Singh Lalatendu Mohanty Ross Smith - Current status: Ross has created an initial spec file for packaging the userspace portions of OpenAFS, based on the spec file from upstream OpenAFS 1.6.9. - Next step: We need to figure out what to do about the kernel modules. - Andrew asks about the system for triggering builds based on kernel uploads. Karanbir says the old system (this is maybe the 'distro buildsystem'?) supported these triggers/hooks, but the new buildsystem with Koji does not (yet?). The old system is being phased out and SIGs should only submit packages via Koji, so this 'triggers' approach is not usable yet. Karanbir mentioned a possible workaround, which I think is just what was mentioned on the list (a hook in the distro buildsystem calls out to Koji). - Andrew raises the issue that such 'triggers' would only cause kmods to be built with new kernel versions; it does not cause new OpenAFS versions to be built against old kernels. Doing so requires building OpenAFS against all older kernel versions upon a new release of OpenAFS. Karanbir explains that while the extra load caused by this is not a problem, you can't just build "foreach" kernel version, and in fact many of the older kernel releases get deleted, so they will not be available to build against. One way of moving forward is to just not build kmods for kernels older than the current openafs release, but this will be a problem for sites that want to upgrade OpenAFS without upgrading their kernel. - Jonathan notes that if we restrict this to EL7 and newer, at least for now, the number of kernels is much smaller. Since in addition to just having fewer kernel revisions, there are fewer variants (x86, PAE, etc). - Karanbir suggests that for now, we just go with the easiest thing that at least minimally works (e.g. just akmods or DKMS). Working out how to handle plain kmods can be deferred and based on user feedback. - Jonathan raises the question of akmods vs DKMS; why do akmods seem more popular? Karanbir's answer involved something about the dependencies, but I did not catch (or have forgotten) the details. - Karanbir asks if he should start pushing the existing packaging into the buildsystem and into CentOS. Andrew suggests we should wait until at least something with the kernel modules is figured out, and a little more testing with the server components. Ross mentions he just tested the client portions, using an upstream kmod. - Andrew solicits opinions on the existence of the 'compat' and/or 'transarc' packages (at least for now); no objections, and no strong opinions on whether these remain as two separate packages or as one. The names openafs-compat and openafs-transarc may not be clear for new users, but their meanings are clear for older users of OpenAFS (who are the only people that care about them). - Andrew asks about what the 'Packager' should be set to in the spec file. Lalatendu I think mentioned we can just set it to the Storage SIG, and we don't need to specify an email address. - Andrew asks about obtaining access to try building packages through Koji. I think the response was that this is pretty open and easy to obtain (at least for sandbox testing), and I just need to go look at it. [I'm sure more specific information was given to me here, but I didn't hear it, sorry.] So, based on that meeeting, here is what I think the next actions are: - Ross is to try a pass at packaging the kernel module via a separate spec file, without worrying about regular kmods; just dynamically building the modules on the client machine is fine for now. - Andrew is to test and try out the servers in the existing packages. - Andrew will create 'compat' and 'transarc' packages (I'll submit pull requests). (Or if Ross or anyone else wants to, go ahead, but I assume I am to do this if I don't hear anything else.) -- Andrew Deason adeason(a)sinenomine.net

1 0

openafs userspace packages
by ross smith 01 Oct '14

01 Oct '14

Hello Everyone, I have been working on reworking the upstream spec file to work with centos. I've been keeping track of my progress on my github page [1] and I welcome pull requests if you find a problem. I have pulled out all of the code related to the building the kmod, as I think that should at least be rewritten from scratch and quite possibly should live in it's own spec file. I did turn off the transarch paths configure option, which will break external scripts that expect the legacy paths. Turning off the transarch paths also meant I had to put moved files back into subpackages and I might have misplaced some files and not noticed. Finally, I've gotten the userspace packages building in koji [2] with minimal testing. Use at your own risk; they might kick kittens. Note that these are only userspace packages. You'll need the kmod from some other source to make the client work. Ross Smith [1] https://github.com/gaurdro/openafs [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7703952

4 6

docker 1.2.0 in virt7-testing
by Lokesh Mandvekar 30 Sep '14

30 Sep '14

I have tagged docker 1.2.0 (tracks upstream 1.2.0) and cockpit 0.24 with virt7-testing. So, I guess that should make them available on a wider scale. FYI, cockpit 0.24 needed glib2 and glib-networking updates, both tagged virt7-testing as well. Let me know how it works (or explodes) for you :) -- Lokesh Freenode, OFTC: lsm5

4 5

Minutes for CBS/Infra Meeting 29-Sep-2014 13:00 UTC
by Brian Stinson 29 Sep '14

29 Sep '14

Meeting started by bstinson at 13:01:13 UTC. The full logs are available at: http://www.centos.org/minutes/2014/september/centos-devel.2014-09-29-13.01.… Meeting summary --------------- * Agenda (bstinson, 13:01:22) * Greetings (bstinson, 13:01:24) * Status Updates (bstinson, 13:01:26) * Auth for git.c.o (bstinson, 13:01:28) * SIG branch/build-target naming (bstinson, 13:01:30) * Building embargoed content (bstinson, 13:01:32) * Open Floor (bstinson, 13:01:34) * Greetings (bstinson, 13:01:36) * Status Updates (bstinson, 13:03:40) * ShellShock got in the way, explaining status on various things (Arrfab, 13:07:46) * Blockers: Test repositories (bstinson, 13:14:32) * ACTION: kbsingh to create usernames/pass on git.centos.org to test the git -> koji interaction (Arrfab, 13:19:49) * ACTION: Arrfab to create two git repositories for cbs usage to hold scripts/automation and everything around cbs (Arrfab, 13:30:07) * Building embargoed content (bstinson, 13:34:14) * Embargoed content will be built locally for testing, and pushed/built in CBS once the embargo expires (bstinson, 13:56:08) * ACTION: bstinson will write up an "Embargoed Content" section for using centpkg mockbuild (bstinson, 13:57:55) * ACTION: : arrfab to discuss a plan with kbsingh to provide access to a VM for those embargo'ed builds with centpkg (Arrfab, 14:02:16) * ACTION: validate and communicate (update wiki) on available testing repositories. (alphacc, 14:02:57) * Open Floor (bstinson, 14:06:10) * ACTION: arrfab to fix default route on koji builder to remove internet access (Arrfab, 14:08:40) * Congrats to the CentOS Core Sig for the 5.11 release (bstinson, 14:09:39) Meeting ended at 14:10:29 UTC. Action Items ------------ * kbsingh to create usernames/pass on git.centos.org to test the git -> koji interaction * Arrfab to create two git repositories for cbs usage to hold scripts/automation and everything around cbs * bstinson will write up an "Embargoed Content" section for using centpkg mockbuild * : arrfab to discuss a plan with kbsingh to provide access to a VM for those embargo'ed builds with centpkg * validate and communicate (update wiki) on available testing repositories. * arrfab to fix default route on koji builder to remove internet access Action Items, by person ----------------------- * arrfab * : arrfab to discuss a plan with kbsingh to provide access to a VM for those embargo'ed builds with centpkg * arrfab to fix default route on koji builder to remove internet access * Arrfab * Arrfab to create two git repositories for cbs usage to hold scripts/automation and everything around cbs * bstinson * bstinson will write up an "Embargoed Content" section for using centpkg mockbuild * kbsingh * kbsingh to create usernames/pass on git.centos.org to test the git -> koji interaction * : arrfab to discuss a plan with kbsingh to provide access to a VM for those embargo'ed builds with centpkg * **UNASSIGNED** * validate and communicate (update wiki) on available testing repositories. People Present (lines said) --------------------------- * kbsingh (64) * MerlinTHP (56) * bstinson (46) * Arrfab (32) * alphacc (27) * mikem (12) * Evolution (3) * centbot (3) * TrevorH (2) * arrfab (0) * quaid (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Re: [CentOS-devel] centos 6 to 7 upgrade tool report
by Bert 29 Sep '14

29 Sep '14

To David Mansfield, My name is Bert, I'm on the Centos-Doc mailing list and I've been doing a bit of further write up on the C6.5 -> C7 upgrade process - basically on how to avoid common problems and pitfalls. In other words, give the user the best experience possible. I've been doing a fair bit of experimenting before I go ahead and "put up a bunch of suggested ways of doing things to avoid problematic upgrades" and would like to share what I've learnt so far, and ask for some more info. Regarding issue #1: I too did an upgrade on that had an NTFS partition (was for dual-boot Windows 2008R2). I commented out the mountpoint in /etc/fstab BEFORE doing the upgrade (as removing ntfs3g would obviously cause mount to complain it didn't know about the partition, and there's no FUSE add-ons in the upgrade image kernel) and that avoided any problems for me. It is helpful to know from your experience that the upgrade process ended up in an emergency shell. This will scare some people, so I will be adding a specific note about checking for mount points (specifically that use FUSE add-ons) and a suggestion to comment them out of /etc/fstab before running the preupgrade advisor. I suggest commenting them out and unmounting before running the advisor because (from what I gather) the tool scans and any all mount points collecting a list of files, which wastes time on the NTFS partition. You wouldn't expect someone to install Linux-related libraries or executables on their NTFS partition... though you never know. One system of mine also had a md RAID6 array, which I unmounted and commented out for the same reasons above. After the upgrade, yum isntall ntfs-3g went as expected, and un-commenting the mountpoint got it mounting again. I'm glad that worked for you in the end. Perhaps there are issues with automount that you were encountering prior to the upgrade. With the new Regarding issue #2: My write-up basically guides the user through removing (read as exorcising if you'll pardon the expression) anything X Window System and Gnome related before running the upgrade advisor (at least for the last time). I include the X window system packages because there have been a few changes that I suspect would lead to a "bad experience". Some preferences seem to have been brought across after a re-install once running C7. There was a couple of tricks I did before the upgrade. 1. Change to runlevel 3 so the GUI doesn't start up straight after the upgrade. (i.e. get to a text-only shell) so we can re-install our GUI aftewards. 2. Removed X, Gnome and MESA packages. I had disabled NetworkManager and for the interfaces in the ifcfg scripts so I can't comment on NM-related issues but there were a few niggles after the upgrade. Post upgrade... yum groups mark convert to fix the group package assignment changes between C6 and C7. yum groups install "GNOME Desktop" "Graphical Administration Tools" to install GNOME again... It's no longer "yum groupinstall ....." This more/less got GNOME up and running again for me (via VNC server) Once in GNOME, use the package maanger to install anything else. /etc/inittab is no longer relevant. Use ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target to get X and your window manager starting up by default. Network manager: Was starting again by default. Once I got around that, and switching over to fiewall-cmd (from plain IPTABLES) and setting up an appropriate zone, my networking has been fine. May I ask, why did you choose to install MATE? Could you not get GNOME working? Can anyone else comment on NM? (before and after) Cheers, Bert ------------------------------ Message: 5 Date: Fri, 26 Sep 2014 10:00:15 -0400 From: David Mansfield <centos(a)dm.cobite.com> To: centos-devel(a)centos.org Subject: [CentOS-devel] centos 6 to 7 upgrade tool report Message-ID: <5425716F.5080402(a)dm.cobite.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi All, I used the upgrade tool on a centos 6.5 fully-updated system, used as a graphical workstation with GDM and gnome2. Before going into details, I want to thank the CentOS team for all the hard work over the years, and especially the top-notch effort to get C7 out, and kudos to the individuals getting the upgrade tool to work too. I feel spoiled. Back to the story: The system had significant use of 3rd party repositories. After I ran the pre-upgrade tool, I used the report of "unsigned" packages (which includes the source repo in the report, which is very useful) to remove all of these packages before update. I ran the tool again and was satisfied that the list of inplace upgrade risks was acceptable and ran the update. Issue#1: The system upgraded and rebooted to the emergency recovery shell. This was because an NTFS partition could not be mounted (ntfs-3g not installed by default during upgrade for some reason). This was somewhat a problem for the user before the upgrade, so I cannot be 100% sure that mounting this a boot was always working 100% before. Solution#1 I commented it from fstab and rebooted - 1st problem solved (see Issue#4 below). Issue#2: The system booted to a black screen with a movable mouse cursor - GDM not working. I tried a bunch of things - uninstalling GNOME stuff, re-installing, installing a bunch of package groups. This one had me stumped for quite a while. Solution#2 Ultimately, the solution was (I believe) that some modifications in /etc/pam.d needed to be merged from the .rpmnew files. On this system, I don't believe the pam.d configuration had been modified from defaults, so I copied the .rpmnew files over (beware: this can be dangerous) and voila! Issue#3: I installed MATE Desktop from epel, and things looked good except that NetworkManager wasn't running: Solution#3: service NetworkManager start chkconfig NetworkManager on Issue#4: Back to the NTFS volume not mounting. Solution#4: I installed ntfs-3g packages and everything mounts fine through nautilus, which is all the user needs. Now everything I could test is working, spice client, Citrix client, google-chrome, vlc, rhythmbox playing mp3s, handbrake (thanks "nux" again), VPN etc. Hope this helps, I was going to update the wiki, but there's no edit button! -- Thanks, David Mansfield Cobite, INC.

2 1

Wallpaper
by Andrew Ognev 29 Sep '14

29 Sep '14

Hello I'm submitting a wallpaper I have made. It is based on 3D model made of CentOS logo. https://github.com/CentOS/Artwork/blob/master/Wallpaper_3d_logo.png Sincerely, Andrew Ognev

6 7

Atomic SIG: Choosing a chair
by Joe Brockmeier 27 Sep '14

27 Sep '14

Hi all, As pointed out at the first Atomic SIG weekly meeting, we need to choose a chair for the SIG. Current members of the SIG: - Joe Brockmeier - Jason Brooks - Greg DeKoenigsberg - Adam Miller - Jim Perrin - Brian Proffit Do we have any nominations or folks who want to serve? The SIG chair will interface with the CentOS board, make requests on behalf of the SIG, be responsible for running meetings, etc. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

3 3

Re: [CentOS-devel] Critical update for bash was released today.
by Nico Kadel-Garcia 27 Sep '14

27 Sep '14

Given the mod_cgi effects, especially for Nagios and other servers, I'd urge caution and stage environment testing before mass deployment. Nico Kadel-Garcia Email: nkadel(a)gmail.com Sent from iPhone

5 7

CentOS Firewall and UTM SIG
by Shafiee Roozbeh 26 Sep '14

26 Sep '14

Hello everybody is it any Firewall and UTM SIG based on IPTables and web interface in CentOS project? I would like to start this if is not exist. what's your idea? -- Roozbeh Shafiee Linux/BSD System Administrator and Python Developer RoozbehShafiee.Com

8 24

centos 6 to 7 upgrade tool report
by David Mansfield 26 Sep '14

26 Sep '14

Hi All, I used the upgrade tool on a centos 6.5 fully-updated system, used as a graphical workstation with GDM and gnome2. Before going into details, I want to thank the CentOS team for all the hard work over the years, and especially the top-notch effort to get C7 out, and kudos to the individuals getting the upgrade tool to work too. I feel spoiled. Back to the story: The system had significant use of 3rd party repositories. After I ran the pre-upgrade tool, I used the report of "unsigned" packages (which includes the source repo in the report, which is very useful) to remove all of these packages before update. I ran the tool again and was satisfied that the list of inplace upgrade risks was acceptable and ran the update. Issue#1: The system upgraded and rebooted to the emergency recovery shell. This was because an NTFS partition could not be mounted (ntfs-3g not installed by default during upgrade for some reason). This was somewhat a problem for the user before the upgrade, so I cannot be 100% sure that mounting this a boot was always working 100% before. Solution#1 I commented it from fstab and rebooted - 1st problem solved (see Issue#4 below). Issue#2: The system booted to a black screen with a movable mouse cursor - GDM not working. I tried a bunch of things - uninstalling GNOME stuff, re-installing, installing a bunch of package groups. This one had me stumped for quite a while. Solution#2 Ultimately, the solution was (I believe) that some modifications in /etc/pam.d needed to be merged from the .rpmnew files. On this system, I don't believe the pam.d configuration had been modified from defaults, so I copied the .rpmnew files over (beware: this can be dangerous) and voila! Issue#3: I installed MATE Desktop from epel, and things looked good except that NetworkManager wasn't running: Solution#3: service NetworkManager start chkconfig NetworkManager on Issue#4: Back to the NTFS volume not mounting. Solution#4: I installed ntfs-3g packages and everything mounts fine through nautilus, which is all the user needs. Now everything I could test is working, spice client, Citrix client, google-chrome, vlc, rhythmbox playing mp3s, handbrake (thanks "nux" again), VPN etc. Hope this helps, I was going to update the wiki, but there's no edit button! -- Thanks, David Mansfield Cobite, INC.

1 0

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