Re: Local DNSSEC resolver and Fedora cloud
On Thursday, 13 August 2015 9:15 AM, Matthew Miller wrote: Many people are at Flock this week. Please have patience. On Thursday, 13 August 2015 10:06 AM, Haïkel wrote: Most of the Cloud WG is in Rochester so I can only second Matthew statement. Oh right, okay. Thank you. --- Regards -P J P http://feedmug.com ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: using fstrim to save some space in cloud images
On Wed, Jun 17, 2015 at 6:45 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Jun 17, 2015 at 06:12:00PM -0400, Dusty Mabe wrote: Have we considered running fstrim against our cloud image filesystems before we package it up? I wrote a small script to do it (inside a container) at [1]. Looks like we can save ~28M: Yeah, we tried it before, and it was failing in the image build process. I don't remember the current state. I am at Flock and I am very interested in helping with this. I have used rsync (from a live CD) to clone old disk to a new disk without copying over deleted files. That is very hard to automate though. I tried it with Fedora cloud images in May and I achieved a similar reduction in space. -Mike ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ecryptfs on F21 EC2 instance
Greetings, If this is the wrong list, kindly point me to the correct one. I am trying to get ecryptfs running on a Fedora 21 EC2 instance on Amazon’s AWS service. Not having any luck whatsoever, I brought up a virtual F21 on my desktop computer in VMWare Fusion to test the procedure to get ecryptfs running, and was successful. Some info about my EC2 instance: AMI: Fedora-Cloud-Base-20141203-21.x86_64-us-east-1-0 Kernel ID: aki-919dcaf8, Kernel image name: pv-grub-hd0_1.04-x86_64.gz Kernel release: 4.1.4-100.fc21.x86_64 Kernel version: #1 SMP Tue Aug 4 03:25:05 UTC 2015 Virtualization: paravirtual When running ecryptfs-setup-private, I get the following error: ERROR: Cannot get ecryptfs version, ecryptfs kernel module not loaded? I tried sudo modprobe ecryptfs and got the following error: modprobe: FATAL: Module ecryptfs not found. This command succeeded while testing on the VMWare instance. Looking at https://fedoraproject.org/wiki/Security_Features_Matrix it indicates that eCryptfs is an optional package in F21. Is this referring to the ecryptfs-utils package, or the kernel module, or both? Can eCryptfs be used on an Amazon EC2 instance, and if so, how do I get the kernel module installed? Thanks Ron Wagner ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: using fstrim to save some space in cloud images
On Thu, Aug 13, 2015 at 02:00:11PM -0400, Michael DePaulo wrote: Yeah, we tried it before, and it was failing in the image build process. I don't remember the current state. I am at Flock and I am very interested in helping with this. Cool -- thanks for not forgetting about this thread. :) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Local DNSSEC resolver and Fedora cloud
On 08/11/2015 02:05 PM, P J P wrote: Hello all, As we know, Fedora-23 Alpha release has just been announced. Which means, most of the proposed features which are approved for F23 are in reasonably good shape for us to try out. One of the proposed system wide change is to install and enable local DNSSEC validating resolver across Fedora variants. - https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver This features proposes to install unbound[1] DNSSEC resolver along with the dnssec-trigger[2] tool, which is used to dynamically configure the 'unbound' resolver. Upon successful setup, user would have the unbound[1] DNSSEC resolver listening on the 127.0.0.1:53 address. And the '/etc/resolv.conf' would point to this server as the designated 'nameserver' for the system. Conveniently, this came up at the DNSSEC session yesterday afternoon. I won't speak for the whole group, but I'd be concerned about what cases the resolver would be enabled for. As a user for the cloud image (local virt, AWS) I don't think adding unbound would be much of an improvement. For cloud image deployment scenarios, if DNS security is of importance to my deployment, I can enforce that external to the instance by running one (or several) DNSSEC resolvers that can be shared between my whole fleet. In AWS, you can set up your VPC to configure a custom resolver over DHCP, and there are similar options in Azure/Rackspace/etc. A 1:1 ratio of servers to DNS resolvers seems pretty wasteful to me, especially in an environment where marginal performance increases cost money. So I'd be against enabling a local DNSSEC resolver in the cloud image. For Atomic Host, I think it makes more sense to have a shared resolver. In that case, the host's resolver can be shared by all the tenant containers. Not only do you get to amortize the cost of running Unbound across N containers on the host, but you get shared DNS caching as well. tl;dr: please don't put it in the cloud image, but I think it makes sense for Atomic Host. Both unbound[1] dnssec-trigger[2] packages are available in Fedora since long. And the proposed feature solution is known to work well for majority of the users. Currently work is in progress to ensure that the proposed feature works seamlessly well across all variants and addresses all use-cases for the Fedora users. The feature has been approved for the upcoming F23 release; But we need affirmation from the individual working groups to install and enable this feature in the respective variants. - https://bugzilla.redhat.com/show_bug.cgi?id=1203950 The affirmation would enable us to include the 'dnssec-trigger' 'unbound' packages in the respective Fedora kickstart files. Could we please have your(cloud-WG) consent to enable this feature on the Fedora cloud variant? If you have any concerns/comments/suggestions please let us know here. -- [1] https://unbound.net/ [2] http://www.nlnetlabs.nl/projects/dnssec-trigger/ [3] https://lists.fedoraproject.org/pipermail/cloud/2015-July/005590.html Thank you. ---Regards -P J P http://feedmug.com ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct