-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Images-i... http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Images...
when we get to final and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree
Dennis Gilmore dennis@ausil.us writes:
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image for x86_64
Compared to TC5 images:
1) iptables-services package is missing in RC1
2) SELinux contexts. It gets better :-) In TC5 if you remember we had: # restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0
In RC1 we have only these: # restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
No other changes/issues noticed.
On Thu, Dec 12, 2013 at 03:18:31PM +0100, Vitaly Kuznetsov wrote:
ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image for x86_64
Compared to TC5 images:
- iptables-services package is missing in RC1
This is intentional and by popular demand -- in an IaaS environment, the cloud provider's security groups or equivalent concept provides the firewall. If one wants defense-in-depth it's easy to install iptables-services or firewalld with cloud-init.
- SELinux contexts. It gets better :-)
In TC5 if you remember we had: # restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0
I'm pre-creating the two log files, so they end up right.
In RC1 we have only these: # restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
I tried to be clever with changing ldlinux.sys from immutable and back again but apparently that doesn't do it. (Since this isn't ever actually run on the system, only _before_ the system, and not on EC2 at all, the side-effects of a wrong context should be small.)
I'm more concerned about /var/cache/yum, since that is already precreated and should already be right.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/12/2013 11:44 AM, Matthew Miller wrote:
On Thu, Dec 12, 2013 at 03:18:31PM +0100, Vitaly Kuznetsov wrote:
ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image for x86_64
Compared to TC5 images: 1) iptables-services package is missing in RC1
This is intentional and by popular demand -- in an IaaS environment, the cloud provider's security groups or equivalent concept provides the firewall. If one wants defense-in-depth it's easy to install iptables-services or firewalld with cloud-init.
- SELinux contexts. It gets better :-) In TC5 if you remember we had: #
restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0
I'm pre-creating the two log files, so they end up right.
In RC1 we have only these: # restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
I tried to be clever with changing ldlinux.sys from immutable and back again but apparently that doesn't do it. (Since this isn't ever actually run on the system, only _before_ the system, and not on EC2 at all, the side-effects of a wrong context should be small.)
I'm more concerned about /var/cache/yum, since that is already precreated and should already be right.
Any chance this is something mounted on that directory? That the relabel is not hitting the inode?
Another option would be to just remove this directory. Especially if there is not content. yum would recreate it on the update.
On Thu, Dec 12, 2013 at 02:18:56PM -0500, Daniel J Walsh wrote:
I'm more concerned about /var/cache/yum, since that is already precreated and should already be right.
Any chance this is something mounted on that directory? That the relabel is not hitting the inode?
Another option would be to just remove this directory. Especially if there is not content. yum would recreate it on the update.
Okay, I'll try that and see how it goes. But note that the fix for the other files was to precreate them -- I'm not... actually sure why that works, but it indicates that something isn't happening right when new files are created at runtime. I've been meaning to talk to you about that. :)
On 12/12/2013 02:29 PM, Matthew Miller wrote:
On Thu, Dec 12, 2013 at 02:18:56PM -0500, Daniel J Walsh wrote:
I'm more concerned about /var/cache/yum, since that is already precreated and should already be right.
Any chance this is something mounted on that directory? That the relabel is not hitting the inode?
Another option would be to just remove this directory. Especially if there is not content. yum would recreate it on the update.
fwiw that's what we did for rhel 7.
Okay, I'll try that and see how it goes. But note that the fix for the other files was to precreate them -- I'm not... actually sure why that works, but it indicates that something isn't happening right when new files are created at runtime. I've been meaning to talk to you about that. :)
Matthew Miller mattdm@fedoraproject.org writes:
On Thu, Dec 12, 2013 at 02:18:56PM -0500, Daniel J Walsh wrote:
I'm more concerned about /var/cache/yum, since that is already precreated and should already be right.
Any chance this is something mounted on that directory? That the relabel is not hitting the inode?
Another option would be to just remove this directory. Especially if there is not content. yum would recreate it on the update.
Okay, I'll try that and see how it goes. But note that the fix for the other files was to precreate them -- I'm not... actually sure why that works, but it indicates that something isn't happening right when new files are created at runtime. I've been meaning to talk to you about that. :)
I tried installing F20 from ISO and '/var/cache/yum' has proper 'rpm_var_cache_t' context after install. It seems anaconda has hackaround for that: https://git.fedorahosted.org/cgit/anaconda.git/tree/data/post-scripts/80-set...
I have an (crazy?) idea about how it happened: '/var/cache/yum' belongs to yum and can be installed really early in the install queue before selinux policy is installed. So it gets default 'file_t' instead of 'rpm_var_cache_t'.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Thu, 12 Dec 2013 04:05:55 -0600 Dennis Gilmore dennis@ausil.us escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Images-i... http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Images...
when we get to final and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree
Note, these are the GA images.
Dennis
On Fri, Dec 13, 2013 at 05:47:38AM -0600, Dennis Gilmore wrote:
additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Images-i... http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Images... when we get to final and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree
Note, these are the GA images.
Hey Dennis, will the images going to mirrors be these or the ones with the extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 13 Dec 2013 10:46:16 -0500 Matthew Miller mattdm@fedoraproject.org escribió:
On Fri, Dec 13, 2013 at 05:47:38AM -0600, Dennis Gilmore wrote:
additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Images-i... http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Images... when we get to final and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree
Note, these are the GA images.
Hey Dennis, will the images going to mirrors be these or the ones with the extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the RC1.1 compose was just to respin the install tree making sure that none of the older libreoffice packages were in the tree.
Dennis
On Fri, Dec 13, 2013 at 10:05:05PM -0600, Dennis Gilmore wrote:
Note, these are the GA images.
Hey Dennis, will the images going to mirrors be these or the ones with the extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the RC1.1 compose was just to respin the install tree making sure that none of the older libreoffice packages were in the tree.
Right, sorry, I wasn't clear. I know that part, but I'm wondering what the actual filename going to the mirrors will be. This is important for the web site and short links.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 13 Dec 2013 23:13:01 -0500 Matthew Miller mattdm@mattdm.org escribió:
On Fri, Dec 13, 2013 at 10:05:05PM -0600, Dennis Gilmore wrote:
Note, these are the GA images.
Hey Dennis, will the images going to mirrors be these or the ones with the extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the RC1.1 compose was just to respin the install tree making sure that none of the older libreoffice packages were in the tree.
Right, sorry, I wasn't clear. I know that part, but I'm wondering what the actual filename going to the mirrors will be. This is important for the web site and short links.
We do not change file names when composed. what they are in the RC is what they will be when shipped.
Dennis
On Sat, Dec 14, 2013 at 02:50:50AM -0600, Dennis Gilmore wrote:
Hey Dennis, will the images going to mirrors be these or the ones with the extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the RC1.1 compose was just to respin the install tree making sure that none of the older libreoffice packages were in the tree.
Right, sorry, I wasn't clear. I know that part, but I'm wondering what the actual filename going to the mirrors will be. This is important for the web site and short links.
We do not change file names when composed. what they are in the RC is what they will be when shipped.
I see that the RC1 tree now alo contains Fedora-x86_64-20-20131211.1-sda.qcow2 -- I am pretty sure that it was previously Fedora-x86_64-20-20131211-sda.qcow2, without the .1. That is what I was referring to.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Sat, 14 Dec 2013 14:22:42 -0500 Matthew Miller mattdm@fedoraproject.org escribió:
On Sat, Dec 14, 2013 at 02:50:50AM -0600, Dennis Gilmore wrote:
Hey Dennis, will the images going to mirrors be these or the ones with the extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the RC1.1 compose was just to respin the install tree making sure that none of the older libreoffice packages were in the tree.
Right, sorry, I wasn't clear. I know that part, but I'm wondering what the actual filename going to the mirrors will be. This is important for the web site and short links.
We do not change file names when composed. what they are in the RC is what they will be when shipped.
I see that the RC1 tree now alo contains Fedora-x86_64-20-20131211.1-sda.qcow2 -- I am pretty sure that it was previously Fedora-x86_64-20-20131211-sda.qcow2, without the .1. That is what I was referring to.
the .1 is refering to the RC that it was. there is issues using just the date, it clashes with the nightly images for one. if we had done a rc2 there would have been a .2 at the end.
going forward Im going to name the images as we do for ARM and livecds
Dennis