Re: [Test-Announce] Fedora 23 Final Test Compose 10 (TC10) and Test Compose 11 (TC11) Available Now!
by Dusty Mabe
On 10/16/2015 12:21 PM, Adam Williamson wrote:
> As scheduled [1], Fedora 23 Final Test Compose 10 (TC10) and TC11 are
> now available for testing. Please help us complete all the validation
> testing!
>
Hey Adam/Cloud list,
Does anyone know what happened between TC9 / TC10 / TC11 with regards to
the Fedora cloud base image? Here is what I notice:
- TC9 boots fine but is affected by
https://fedorahosted.org/cloud/ticket/128
- TC10 does not boot. It is using syslinux!!! This is a big change that
should not have happened.
- TC11 boots fine but the kbd rpm is missing so the
systemd-vconsole-setup.service systemd unit fails on boot.
Any insight here?
Dusty
8 years, 5 months
Error: "unable to process Dockerfile: unable to parse repository info: repository name component must match:"
by Philip Rhoades
People,
I updated docker on F22 from:
docker-1.7.1-8.gitb6416b7.fc22.x86_64
docker-selinux-1.7.1-8.gitb6416b7.fc22.x86_64
to the latest:
docker-1.8.2-1.gitf1db8f2.fc22.x86_64
docker-selinux-1.8.2-1.gitf1db8f2.fc22.x86_64
and tried doing a:
docker build .
in an existing directory and Dockerfile that I have been using before
and I get the error above - the regex that follows:
"[a-z0-9]+(?:[._-][a-z0-9]+)*"
is insisting on all lower case but my previous Docker Base Image was:
Fedora-Docker-Base-23_Alpha-20150805.x86_64.tar.xz
and I just tried:
Fedora-Docker-Base-23_Beta-20150915.x86_64.tar.xz
with no luck either so I renamed this to:
fedora-docker-base-23_beta-20150915.x86_64.tar.xz
and reloaded it and changed the name in the Docker file but of course
then grabbing stuff from the repo doesn't work . .
What is going on? Have I messed up something somehow?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
8 years, 5 months
network service failing on F23 base image
by Kushal Das
Hi all,
For the last few days we can see that the *network* service is failing
on Fedora 23 Cloud base images [1].
Upon digging more in the issue, I found the following in the journal.
Oct 12 19:03:40 localhost.localdomain systemd[1]: Starting LSB: Bring up/down networking...
Oct 12 19:03:41 localhost.localdomain network[424]: Bringing up loopback interface: [ OK ]
Oct 12 19:03:51 testcloud.localdomain network[424]: Bringing up interface ens3: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device ens3 does not seem to be present
Oct 12 19:03:51 testcloud.localdomain /etc/sysconfig/network-scripts/ifup-eth[680]: Device ens3 does not seem to be present, delaying initialization.
Oct 12 19:03:51 testcloud.localdomain network[424]: [FAILED]
Oct 12 19:03:51 testcloud.localdomain network[424]: Bringing up interface eth0:
Oct 12 19:03:51 testcloud.localdomain dhclient[702]: Created duid \000\001\000\001\035\256\300\227RT\000\036hd.
Oct 12 19:03:51 testcloud.localdomain dhclient[702]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x7e6c2257)
Oct 12 19:03:53 testcloud.localdomain dhclient[702]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x7e6c2257)
Oct 12 19:03:53 testcloud.localdomain dhclient[702]: DHCPOFFER from 192.168.122.1
Oct 12 19:03:53 testcloud.localdomain dhclient[702]: DHCPACK from 192.168.122.1 (xid=0x7e6c2257)
Oct 12 19:03:55 testcloud.localdomain NET[730]: /usr/sbin/dhclient-script : updated /etc/resolv.conf
Oct 12 19:03:56 testcloud.localdomain dhclient[702]: bound to 192.168.122.83 -- renewal in 1756 seconds.
Oct 12 19:03:56 testcloud.localdomain network[424]: Determining IP information for eth0... done.
Oct 12 19:03:56 testcloud.localdomain network[424]: [ OK ]
Oct 12 19:03:56 testcloud.localdomain systemd[1]: network.service: Control process exited, code=exited status=1
Oct 12 19:03:56 testcloud.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
Oct 12 19:03:56 testcloud.localdomain systemd[1]: network.service: Unit entered failed state.
Oct 12 19:03:56 testcloud.localdomain systemd[1]: network.service: Failed with result 'exit-code'.
While trying to find out a solution, I was pointed to [2]. I tried to follow
the initial solution given there and added * biosdevname=0 net.ifnames=0* on
the network section in the kickstart, and did a local build. But it still
failed with the same issue. So, the only *easy* solution I can think of
is actually deleting the file */etc/sysconfig/network-scripts/ifcfg-ens3* in the
post installation section of the kickstart file. If there is no other better
solution than this, I will go ahead and commit that for F23, and master.
[1] https://apps.fedoraproject.org/autocloud/jobs/255/output
[2] https://access.redhat.com/discussions/916973
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
CentOS Cloud SIG lead
http://kushaldas.in
8 years, 5 months
Becoming comaintainer for Fedora-Dockerfiles
by Bohuslav Kabrda
Hi everyone,
just a quick heads-up: I offered my help with maintaining Fedora-Dockerfiles [1] to Scott who accepted it, so I'm jumping in. In the following months, I'd like to keep number of opened pull requests and issues at minimum and also sort out some more complex issues like:
- setting up CI
- automatic pushing of tested images to dockerhub
- cleanup of contribution guidelines, readmes, etc
I think that setting up CI is the most important thing to do right now, since hand testing the images is both error prone and time consuming. I'll try to keep the track of my thoughts and the overall progress in this at [2].
One of the things that I forgot to talk about with Scott was the relation of Fedora-Dockerfiles to Layered Image Build System proposal [3]. The proposal suggests that dist-git should be set up for Dockerfiles. Are there any plans to obsolete Fedora-Dockerfiles to dist-git repos? Or are these meant to run in parallel and have different purposes? I'd like to get answers to these questions before I start working on any of the issues mentioned above. (If there are no answers yet, then I'm happy to participate in the discussion!)
So to sum things up, I'm here for you now as another maintainer of Fedora-Dockerfiles. Feel free to communicate with me through the Github issue tracker, through this list, IRC (#fedora-devel is where I usually lurk) or my private mail.
Thank you for your attention :)
--
Regards,
Slavek Kabrda
[1] https://github.com/fedora-cloud/Fedora-Dockerfiles
[2] https://fedorahosted.org/cloud/ticket/124
[3] https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
8 years, 5 months
Re: selinux denials when starting docker in F23
by Dusty Mabe
On 10/12/2015 06:09 AM, Miroslav Grepl wrote:
> On 10/11/2015 01:41 PM, Daniel J Walsh wrote:
>>
>> On 10/10/2015 09:09 AM, Dusty Mabe wrote:
>>>
>>> On 10/10/2015 08:02 AM, Daniel J Walsh wrote:
>>>> On 10/09/2015 01:07 PM, Bruno Wolff III wrote:
>>>>> On Fri, Oct 09, 2015 at 12:43:52 -0400,
>>>>> Dusty Mabe <dusty(a)dustymabe.com> wrote:
>>>>>> On 10/08/2015 03:06 PM, Dusty Mabe wrote:
>>>>>>> and this is in the journal:
>>>>>>>
>>>>>>> ```
>>>>>>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>>>>>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>>>>>> msg='Unknown permission stop for class system
>>>>>>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>>>>>>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>>>>>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>>>>>> msg='Unknown permission stop for class system
>>>>>>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>>>>>>> ```
>>>>>> Any comments on the USER_AVC statements? Even if I have docker.pp I
>>>>>> still see these.
>>>>> I got something similar running getmail from cron. I asked about it on
>>>>> the selinux list but didn't get any suggestions on how to make a rule
>>>>> to allow this (audit2allow doesn't seem to handle this avc.)
>>>>> _______________________________________________
>>>>> cloud mailing list
>>>>> cloud(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>>> If you systemctl daemon-rexec does the problem go away?
>>> No, I still see them. I did an reexec and then started and stopped a
>>> container. The `USER_AVC` messages get spit out to the journal on both
>>> start and stop.
>>>
>>> ```
>>> [root@footest ~]# journalctl -f | grep USER_AVC &
>>> [1] 11388
>>> [root@footest ~]# docker run -it --rm busybox /bin/sh
>>> Oct 10 13:08:16 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
>>> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
>>> permission start for class system exe="/usr/lib/systemd/systemd"
>>> sauid=0 hostname=? addr=? terminal=?'
>>> / #
>>> / # exit
>>> Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
>>> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
>>> permission stop for class system exe="/usr/lib/systemd/systemd"
>>> sauid=0 hostname=? addr=? terminal=?'
>>> Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
>>> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
>>> permission stop for class system exe="/usr/lib/systemd/systemd"
>>> sauid=0 hostname=? addr=? terminal=?'
>>> ```
>> So this means that selinux policy does not define a start call for the
>> system class. Meaning this is either a bug in systemd, systemd is
>> asking for a start access on system when it should be asking for it on a
>> service. Or selinux-policy needs to add a start permission for system.
>> I am thinking this is probably a problem with systemd. Adding
>> Miroslav to
>> see if he knows.
>>
> What OS? This is a systemd bug. AFAIK they added some fixes for it.
Fedora 23 beta cloud image [1] is where I started. I then fully updated
the system (dnf update -y) and rebooted before installing docker. Just
installing/starting docker gives me the USER_AVCs. If they fixed some
stuff it isn't in F23.
Dusty
[1] -
http://mirror.sfo12.us.leaseweb.net/fedora/linux/releases/test/23_Beta/Cl...
8 years, 5 months
selinux denials when starting docker in F23
by Dusty Mabe
Hey guys anybody seen these when starting
docker-1.8.2-5.gitcb216be.fc23.x86_64:
```
Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc: denied {
read } for pid=1513 comm="iptables" path="net:[4026531957]" dev="nsfs"
ino=4026531957 scontext=system_u:system_r:iptables_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
```
Nevertheless the docker daemon is up and running but if I start a
container and then force remove it I see:
```
Error deleting container: Error response from daemon: Cannot destroy
container
710f834e316946a422a00fb3470b895b387519ecb01a5b195cc818b9764f82a7: Failed
to set container state to RemovalInProgress: Status is already
RemovalInProgress
```
and this is in the journal:
```
Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='Unknown permission stop for class system
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='Unknown permission stop for class system
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
```
8 years, 5 months
Cloud Meeting Minutes 2015-10-07
by Dusty Mabe
html version: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-07/cloud_wg.201...
text version: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-07/cloud_wg.201...
=========================
#fedora-meeting-1 Meeting
=========================
Meeting started by dustymabe at 17:02:30 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-07/cloud_wg.201...
.
Meeting summary
---------------
* rollcall (dustymabe, 17:02:42)
* LINK:
https://meetbot.fedoraproject.org/sresults/?group_id=fedora-meeting-1&typ...
(dustymabe, 17:06:50)
* LINK:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-23/cloud_w...
(roshi, 17:08:17)
* last meeting items (dustymabe, 17:09:21)
* LINK: https://fedorahosted.org/cloud/ticket/94 (dustymabe,
17:10:11)
* LINK: https://fedoraproject.org/wiki/Cloud/Network-Requirements
(maxamillion, 17:10:42)
* LINK: https://fedoraproject.org/wiki/Cloud/Network-Requirements
(dustymabe, 17:11:29)
* maxamillion spoke with mhayden and he updated the wiki page
(dustymabe, 17:11:40)
* Migrate all Dockerfiles / Images to systemd where possible
(dustymabe, 17:13:48)
* LINK: https://fedorahosted.org/cloud/ticket/121 (dustymabe,
17:13:57)
* Migrate all Dockerfiles / Images to systemd where possible
(dustymabe, 17:17:51)
* LINK: https://fedorahosted.org/cloud/ticket/121 (dustymabe,
17:17:59)
* fedora-dockerfiles: Clean up READMEs. (dustymabe, 17:18:25)
* LINK: https://fedorahosted.org/cloud/ticket/122 (dustymabe,
17:18:34)
* Document process for using Fedora-Dockerfile branches (dustymabe,
17:21:24)
* LINK: https://fedorahosted.org/cloud/ticket/123 (dustymabe,
17:21:30)
* CI for Fedora-Dockerfiles (dustymabe, 17:24:07)
* LINK: https://fedorahosted.org/cloud/ticket/124 (dustymabe,
17:24:15)
* Fedora-Dockerfiles examples for Kubernetes (dustymabe, 17:29:45)
* LINK: https://fedorahosted.org/cloud/ticket/125 (dustymabe,
17:29:53)
* open floor (dustymabe, 17:32:42)
* LINK: https://apps.fedoraproject.org/autocloud/jobs/ is finally on
production (kushal, 17:33:05)
* ACTION: dustymabe to create ticket to figure out python3/ansible
requirements for cloud (dustymabe, 17:40:45)
Meeting ended at 17:45:53 UTC.
Action Items
------------
* dustymabe to create ticket to figure out python3/ansible requirements
for cloud
Action Items, by person
-----------------------
* dustymabe
* dustymabe to create ticket to figure out python3/ansible
requirements for cloud
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (108)
* roshi (30)
* kushal (20)
* adimania (20)
* maxamillion (17)
* zodbot (12)
* jbrooks (6)
* number80 (2)
* gholms (2)
* rtnpro (2)
* smdeep (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 5 months