Planet CentOShttp://planet.centos.org/atom.xml2016-12-10T02:30:05+00:00Planet/2.0 +http://www.planetplanet.orgZabbix, selinux and CentOS 7.3.1611tag:arrfab.net,2016-11-25:posts/2016/Nov/25/zabbix-selinux-and-centos-731611/2016-11-24T23:00:00+00:00<p>If you're using CentOS, you probably noticed that we have a <a href="https://wiki.centos.org/AdditionalResources/Repositories/CR">CR repository</a> containing all the built packages for the next minor release, so that people can "opt-in" and already use those packages, before they are released with the full installable tree and iso images.</p>
<p>Using those packages on a subset of your nodes can be interesting, as it permits you to catch some errors/issues/conflicts before the official release (and so symlink on mirrors being changed to that new major.minor version)</p>
<p>For example, I tested myself some roles and found an issue with zabbix-agent refusing to start on a node fully updated/rebooted with CR pkgs (so what will become 7.3.1611 release). The issue was due to selinux denying something (that was allowed in previous policy)</p>
<p>Here is what selinux had to say about it : </p>
<div class="highlight"><pre>type=AVC msg=audit(1480001303.440:2626): avc: denied { setrlimit } for pid=22682 comm=&quot;zabbix_agentd&quot; scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:system_r:zabbix_agent_t:s0 tclass=process
</pre></div>
<p>It's true that there was an update for selinux policy : from selinux-policy-3.13.1-60.el7_2.9.noarch to selinux-policy-3.13.1-102.el7.noarch.</p>
<p>What's interesting is that I found the reported issue at Zabbix side, but for zabbix-server (here it's the agent, server is running fine) : <a href="https://support.zabbix.com/browse/ZBX-10542">ZBX-10542</a></p>
<p>Clearly something that was working before and now denied, so I created a <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1398721">bug report</a> and hopefully one fix will come in an updated selinux-policy package. But I doubt that it will be available soon.</p>
<p>So in the mean time, what you have to do is :</p>
<ul>
<li>either put zabbix_agent_t into permissive mode with <code>semanage permissive -a zabbix_agent_t</code></li>
<li>either build and distribute a custom selinux policy in your infra (preferred method for me)</li>
</ul>
<p>For those interested, the following .te (type enforcement) will allow you to build a custom .pp selinux policy file (that you can load with semodule) : </p>
<div class="highlight"><pre><span class="nt">module</span> <span class="nt">local-zabbix</span> <span class="nt">1</span><span class="nc">.0</span><span class="o">;</span>
<span class="nt">require</span> <span class="p">{</span>
<span class="n">type</span> <span class="n">zabbix_agent_t</span><span class="p">;</span>
<span class="n">class</span> <span class="n">process</span> <span class="n">setrlimit</span><span class="p">;</span>
<span class="p">}</span>
<span class="err">#</span><span class="o">=============</span> <span class="nt">zabbix_agent_t</span> <span class="o">==============</span>
<span class="nt">allow</span> <span class="nt">zabbix_agent_t</span> <span class="nt">self</span><span class="nd">:process</span> <span class="nt">setrlimit</span><span class="o">;</span>
</pre></div>
<p>You can now use your configuration management platform to distribute that built .pp policy (you don't need to build it on every node). I'll not dive into details, but I wrote <a href="https://people.centos.org/arrfab/Events/Loadays-2014/managing%20selinux%20with%20your%20cfgmgmt%20solution.pdf">some slides</a> around this (for Ansible and Puppet) for a talk I gave some time ago, so feel free to read those, especially the last slides (with examples)</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Updated CentOS Vagrant Images Available (v1610.01)https://seven.centos.org/?p=7662016-11-15T17:23:49+00:00<p>Official Vagrant images for CentOS Linux 6.8 and CentOS Linux 7.2.1511 for x86_64 are now available for download, featuring updated packages to 30 October 2016, as well as the following user-visible changes:</p>
<ul>
<li>several optimisations to make the images smaller and faster:
<ul>
<li>do not install most firmware packages</li>
<li>do not install <code>microcode_ctl</code></li>
<li>do not build a rescue initramfs (resulting in significantly faster kernel updates)</li>
<li>do not load the floppy module on <code>centos/7</code> (this reduces boot time by ca. 5s)</li>
</ul>
</li>
<li><strong>[security]</strong>: do not allow regular users to use <em>su</em> to become <em>root</em> or <em>vagrant</em> &#8211; see <a href="https://github.com/CentOS/sig-cloud-instance-build/issues/76">issue #76</a></li>
<li>set the SELinux type of <em>/etc/sudoers.d/vagrant</em> to <em>etc_t</em></li>
</ul>
<h3>Known Issues</h3>
<ol>
<li>The <code>centos/7</code> image is based on CentOS Linux 7.2.1511, since CentOS Linux 7.3 is not available yet.</li>
<li>The VirtualBox Guest Additions are not preinstalled; if you need them for shared folders, please install the <a href="https://github.com/dotless-de/vagrant-vbguest">vagrant-vbguest</a> plugin and add the following line to your Vagrantfile:
<pre>config.vm.synced_folder “.”, “/vagrant”, type: “virtualbox”</pre>
<p>We recommend <a href="https://www.vagrantup.com/docs/synced-folders/nfs.html">using NFS</a> instead of VirtualBox shared folders if possible.</p></li>
<li>Since the Guest Additions are missing, our images are preconfigured to use rsync for synced folders. Windows users can either use SMB for synced folders, or disable the sync directory by adding the line
<pre>config.vm.synced_folder ".", "/vagrant", disabled: true</pre>
<p>to your Vagrantfile.</p></li>
<li><a id="v186"></a>Please use Vagrant 1.8.6 (version 1.8.5 is unable to create new Linux boxes due to <a href="https://github.com/mitchellh/vagrant/issues/7610">Vagrant bug #7610</a>, while version 1.8.7 is unable to download or update boxes due to <a href="https://github.com/mitchellh/vagrant/issues/7969">Vagrant bug #7969</a>).</li>
<li>Installing <em>open-vm-tools</em> is not enough for enabling shared folders with Vagrant&#8217;s VMware provider. Please follow the detailed instructions in <a href="https://github.com/mvermaes/centos-vmware-tools">https://github.com/mvermaes/centos-vmware-tools</a>.</li>
</ol>
<h3>Downloads</h3>
<p>The official images can be downloaded from Hashicorp’s Atlas. We provide <a href="https://atlas.hashicorp.com/centos/">images</a> for libvirt-kvm, VirtualBox and VMware.</p>
<p>If you never used our images before:</p>
<pre>$ vagrant box add centos/6 # for CentOS Linux 6
$ vagrant box add centos/7 # for CentOS Linux 7
</pre>
<p>Existing users can upgrade their images:</p>
<pre>$ vagrant box update --box centos/6
$ vagrant box update --box centos/7</pre>
<p>If you are using CentOS Linux on the host, we recommend installing <a href="https://wiki.centos.org/SpecialInterestGroup/SCLo/Vagrant">Vagrant from SCL</a> and using the <em>libvirt</em> images. In general, the Vagrant packages provided by your Linux distribution are preferable, since they usually backport fixes for some upstream bugs. If you are using Vagrant on other operating systems, please use Vagrant 1.8.6 (see <a href="https://seven.centos.org/feed/#v186">Known issues, item 4</a>).</p>
<h3>Verifying the integrity of the images</h3>
<p>The SHA256 checksums of the images are signed with the CentOS 7 Official Signing Key. First, download and verify the checksum file:</p>
<pre>$ curl http://cloud.centos.org/centos/7/vagrant/x86_64/images/sha256sum.txt.asc -o sha256sum.txt.asc
$ gpg --verify sha256sum.txt.asc
</pre>
<p>If the check passed, you can use the corresponding checksum when downloading the image with Vagrant:</p>
<pre>$ vagrant box add --checksum-type sha256 --checksum ce12f84646efab28b007bdf16f3134686a23fa052f809c4600919561274051da --provider libvirt --box-version 1610.01 centos/7
</pre>
<p>Unfortunately, this is not possible with <code>vagrant box update</code>.</p>
<h3>Feedback</h3>
<p>If you encounter any unexpected issues with the Vagrant images, feel free to ask on the <a href="http://lists.centos.org/mailman/listinfo/centos-devel">centos-devel</a> mailing list, or via IRC, in #centos on Freenode.</p>
<h3>Ackowledgements</h3>
<p>Some of the optimisations in this release were inspired by the Vagrant images from Fedora Cloud and Debian Cloud.</p>
<p>We would also like to thank the following people (in alphabetical order):</p>
<ul>
<li>Graham Mainwaring, for helping with tests and validations</li>
<li>Michael Vermaes, for testing our official images, as well as for writing the detailed guide to using them with VMware Fusion Pro and VMware Workstation Pro.</li>
</ul>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00Introducing CentOS Container Image Scannershttps://seven.centos.org/?p=7892016-11-10T18:52:36+00:00<p>Over past few months, we&#8217;ve been working on CentOS Community Container Pipeline which aims to help developers focus on what they love doing most &#8211; <strong>write awesome code</strong> &#8211; and sysadmins have an insight into the image by providing metadata about it! The project code is hosted at <a href="https://github.com/CentOS/container-pipeline-service/">Github.com</a> since its inception. The hosted service, that runs off this code, is available to the community at large, and delivers content to registry.centos.org.<br />
<strong>What is CentOS Community Container Pipeline?</strong></p>
<p>CentOS Community Container Pipeline enables developers and sysadmins to have a container images built, tested and scanned on the CentOS Project&#8217;s infrastructure right after a developer pushes code to the git repository!</p>
<p><strong>Container Pipeline Flow</strong></p>
<p>Once the developer pushes code to git repo, Container Pipeline fetches the changes and container images are built using <a href="https://www.openshift.org/">OpenShift</a> which provides an enterprise distribution of <a href="http://kubernetes.io/">Kubernetes</a> project. Once the image is built, it gets scanned using atomic scanners (more on this soon!). The result of these scanners is combined into a mail and sent to the author of the container image. Container images can also be tested using the user provided test scripts to ensure that container can be spinned off the image on platforms like <a href="https://www.centos.org/download/">CentOS Linux</a>, <a href="https://wiki.centos.org/SpecialInterestGroup/Atomic/Download/">CentOS Atomic Host</a> and OpenShift. </p>
<p><strong>Why scan images?</strong></p>
<p>Building container images and spinning containers is rather simple. Having more information a.k.a metadata about the container images before running them in one&#8217;s production environment is of paramount value! Of course, the kind of information is what makes it of paramount or negligible value. That&#8217;s what we aim to provide with CentOS Community Container Pipeline.</p>
<p><strong>Scanners in CentOS Community Container Pipeline</strong></p>
<p>At this point we have two scanners operational. One that checks your CentOS Linux based container images for package updates and other that verifies them. Both the scanners are based on <a href="https://github.com/projectatomic/atomic">atomic</a> tool developed by the <a href="http://www.projectatomic.io/">Project Atomic</a> folks. We are working on rolling out more scanners in near future!</p>
<p><strong>Atomic Scanner</strong></p>
<p>The scanners based on atomic are run automatically by the Pipeline after successful completion of image building process. These scanners can be run stand-alone as well! That is, you can install the scanner on your CentOS Linux based systems and run it against a container image built on CentOS Linux base image. And it does this without bringing up or executing the container itself.</p>
<p>In the pipeline, upon completion of scan process, the user is notified about issues with the image that need to be addressed. Addressing these issues would instill more confidence in deploying the resulting container image in a production environment.</p>
<p>Besides scanning an image after it is built, in near future, scanners would also run periodically and provide developer with the actionable information.</p>
<p><strong>yum update scanner</strong></p>
<p>This scanner provides user with the information about RPM packages that need to be updated in the container image. If you&#8217;re a developer this information is helpful to ensure you&#8217;re running latest packages with bug and security fixes to avoid having surprises in production.</p>
<p>Example output:</p>
<pre>$ atomic scan --scanner pipeline-scanner --rootfs /mnt registry.centos.org/centos/centos
...
Files associated with this scan are in /var/lib/atomic/pipeline-scanner/2016-11-10-10-30-46-609885.
</pre>
<p>Scanner ran succesfully and has stored the scan data under <strong><code>/var</code></strong> directory. Let&#8217;s see the output:</p>
<pre>$ cat /var/lib/atomic/pipeline-scanner/2016-11-10-10-30-46-609885/_mnt/image_scan_results.json
{
"Scanner": "pipeline-scanner",
"Successful": "true",
"Start Time": "2016-11-10-10-42-46-265018",
"Scan Results": {
"Package Updates": [
"bind-license.noarch",
"kmod.x86_64",
"kmod-libs.x86_64",
"kpartx.x86_64",
"openssl-libs.x86_64",
"python.x86_64",
"python-libs.x86_64",
"systemd.x86_64",
"systemd-libs.x86_64",
"tzdata.noarch"
],
"OS Release": "CentOS Linux 7 (Core)"
},
"Scan Type": "Image Scan",
"CVE Feed Last Updated": "NA",
"Finished Time": "2016-11-10-10-42-52-184442",
"UUID": "mnt"
}
</pre>
<p>The <strong><code>Package Updates</code></strong> key in above output lists packages that need to be updated in the scanned container image.</p>
<p><strong>RPM verify scanner</strong></p>
<p>As its name suggests RPM verify scanner verifies all installed files (libraries and binaries) via RPM packages in given container image. It reports any modified or tampered libraries and binaries in given container image. This is useful to ensure that given container image is not shipped with any tainted libraries or binaries.</p>
<p>Example output:</p>
<pre>$ atomic scan --scanner rpm-verify docker.io/centos/postgresql
{
"Scanner": "scanner-rpm-verify",
"Successful": "true",
"Start Time": "2016-11-10-19-49-06-740445",
"Scan Results": {
"rpmVa_issues": [
{
"config": false,
"issue": "missing",
"rpm": {Once the developer pushes code to git repo, Container Pipeline fetches the changes and container images are built using OpenShift which provides an enterprise version of Kubernetes project. Once the image is built, it gets scanned using atomic scanners (more on this soon!). Container images can also be tested using the user provided test scripts to ensure that container can be spinned off the image on platforms like CentOS Linux, CentOS Atomic Host and OpenShift.
"VENDOR": "CentOS",
"PACKAGER": "CentOS BuildSystem ",
"BUILDHOST": "worker1.bsys.centos.org",
"RPM": "glibc-2.17-55.el7_0.1.x86_64",
"SIGNATURE": "RSA/SHA256, Sat Aug 30 02:20:20 2014, Key ID 24c6a8a7f4a80eb5"
},
"filename": "/sbin/sln"
},
{
"config": false,
"issue": "........P",
"rpm": {
"VENDOR": "CentOS",
"PACKAGER": "CentOS BuildSystem ",
"BUILDHOST": "worker1.bsys.centos.org",
"RPM": "iputils-20121221-6.el7.x86_64",
"SIGNATURE": "RSA/SHA256, Fri Jul 4 07:38:44 2014, Key ID 24c6a8a7f4a80eb5"
},
"filename": "/usr/sbin/clockdiff"
}
]
},
"Scan Type": "RPM Verify scan for finding tampered files.",
"CVE Feed Last Updated": "NA",
"Finished Time": "2016-11-10-19-49-10-933952",
"UUID": "da4ffaac638fada8723c6721721d99b0dfaba67d79c8507e881ee8327e17ecb"
}
</pre>
<p><strong>Adding your container to the pipeline</strong></p>
<p>It&#8217;s simple! Add an entry for your opensource project under <strong><code>index.d</code></strong> directory on <a href="https://github.com/CentOS/container-index">CentOS Container Index</a>. You can see a few files representing projects or individual developers under this directory already. Also, you need to have a <strong><code><a href="https://github.com/CentOS/container-index/blob/master/cccp.yml">cccp.yml</a></code></strong> file in your project that has information useful for the Container Pipeline to use. You can refer respective GitHub repos to get more information. Or get in touch with us on #centos-devel IRC channel on FreeNode network.</p>
<p>Dharmit Shah and Navid Shaikh</p>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00Decoding an LLDP packethttp://www.karan.org/blog/?p=2882016-11-07T14:14:12+00:00<p>Running with a switch that provides LLDP info ? You can easily decode that and workout what switch port, what switch etc you are connected to with this one simple snippet :</p>
<blockquote><p>tcpdump -v -s 1500 -c 1 &#8216;(ether[12:2]=0x88cc or ether[20:2]=0x2000)&#8217; -i eth0</p></blockquote>
<p>Ofcourse, replace eth0 with the real device name; and wait a few seconds for the data to show up.</p>
<p>&#8211; KB</p>Karanbir Singhhttp://www.karan.org/blogKaranbir Singh :: Thinkability @karan.orgWake up sleepyhead...http://www.karan.org/blog/feed/2016-11-10T15:11:27+00:00Welcoming new members to the CentOS Container teamhttp://www.karan.org/blog/?p=2842016-11-07T14:08:03+00:00<p>Join me in warmly welcoming <a href="https://twitter.com/dharm1t">Dharmit Shah</a>, <a href="https://twitter.com/bamachrn">Bama Charan Kundu</a> and <a href="https://twitter.com/swordphilic">Navid Shaikh</a> to the CentOS Container team. </p>
<p>They are primarily focused on delivering and curating the <a href="https://github.com/centos/container-index">CentOS Container Pipeline</a> (<a href="https://github.com/centos/container-pipeline-service">https://github.com/centos/container-pipeline-service</a> ). In the coming weeks, keep an eye out for announcements from them in the CentOS Blog at <a href="https://seven.centos.org">https://seven.centos.org</a> .</p>
<p>&#8211; KB</p>Karanbir Singhhttp://www.karan.org/blogKaranbir Singh :: Thinkability @karan.orgWake up sleepyhead...http://www.karan.org/blog/feed/2016-11-10T15:11:27+00:00Vim 8 for CentOS Linux 7http://www.karan.org/blog/?p=2792016-11-05T03:40:34+00:00<p>Matěj Cepl is curating a set of Vim 8 rpms for EL7 over at<br />
<a href="https://copr.fedorainfracloud.org/coprs/mcepl/vim8/">https://copr.fedorainfracloud.org/coprs/mcepl/vim8/</a> &#8211; consider them testing grade, and I am sure he would appreciate feedback and issue reports.</p>
<p>Now go get the shinny new Vim8. </p>
<ul>
<li>Grab the .repo file from <a href="https://copr.fedorainfracloud.org/coprs/mcepl/vim8/repo/epel-7/mcepl-vim8-epel-7.repo">https://copr.fedorainfracloud.org/coprs/mcepl/vim8/repo/epel-7/mcepl-vim8-epel-7.repo</a></li>
<li> drop it into your /etc/yum.repos.d/ </li>
<li>import his key from <a href="https://copr-be.cloud.fedoraproject.org/results/mcepl/vim8/pubkey.gpg">https://copr-be.cloud.fedoraproject.org/results/mcepl/vim8/pubkey.gpg</a> ( sha256sum: fd815cc08aed40165cc67a79f00af61f2f5fdd6be1a3891f40321ae4705f3b18 )</li>
<li> and you should be able to &#8216;yum install vim-enhanced&#8217; to Vim 8.</li>
</ul>
<p><code>$ rpm -q vim-enhanced<br />
vim-enhanced-8.0.0054-1.0.8.el7.centos.x86_64<br />
</code></p>
<p>Enjoy! And dont forget to drop by and say thanks to Matěj over at <a href="https://matej.ceplovi.cz/blog/">https://matej.ceplovi.cz/blog/</a></p>Karanbir Singhhttp://www.karan.org/blogKaranbir Singh :: Thinkability @karan.orgWake up sleepyhead...http://www.karan.org/blog/feed/2016-11-10T15:11:27+00:00Security contact for the CentOS Projecthttp://www.karan.org/blog/?p=2732016-10-27T19:52:58+00:00<p>If you find any security issue in a CentOS.org website or service, please let us know; the same goes for any issues in CentOS Linux as well as the SIG content on centos.org. And the best way to get in touch is to email <a href="mailto:security@centos.org">security@centos.org</a> &#8211; and if the content is sensitive, please use the corrosponding gpg key to encrypt the content with. eg for CentOS Linux 7 specific issue, please encrypt the content with the CentOS Linux 7 key. Similarly for any content specific to the Virt SIG, please use the CentOS SIG Virt key.</p>
<p>How can you verify the keys ? The fingerprints are published behind https at <a href="https://www.centos.org/keys/">https://www.centos.org/keys/</a>.</p>
<p>DNS data for the www.centos.org website is :<br />
<code>www.centos.org has address 85.12.30.226<br />
www.centos.org has IPv6 address 2a01:788:a002:0:225:90ff:fe33:f34c<br />
</code></p>
<p>&#8211; KB</p>Karanbir Singhhttp://www.karan.org/blogKaranbir Singh :: Thinkability @karan.orgWake up sleepyhead...http://www.karan.org/blog/feed/2016-11-10T15:11:27+00:00Adding a timeout for your CI jobs at ci.centos.orghttp://www.karan.org/blog/?p=2672016-10-26T21:10:12+00:00<p>The typical workflow for most ci.centos.org ( cico ) jobs is :<br />
<code><br />
* Call Duffy's API endpoint with node/get and grab some machines<br />
* Setup the machines environment for the ci job to come<br />
* Push content to nodes<br />
* Run the tests<br />
* Clear out / tear down<br />
* Call Duffy's API end point with node/done to return the machines<br />
* Report status via Jenkins<br />
</code></p>
<p>Machines handed out in this manner to the CI Jobs are available for upto 6 hours at a time, at which point they are reaped back into the available pool for other jobs to consume. What this also means is that if for any reason, the job gets stuck, it could be upto six hours before the developer/user gets any feedback about the tests failing.</p>
<p>The usual way to resolve this situation is to setup a timeout in the jenkins job. That would allow Jenkins to watch for the run, on timeout, kill the job and report failure. However, if your job is setup with a single build step that also includes requesting the machines and returning them when done, Jenkins killing the job will mean your machines wont get returned for upto 6 hrs. Given that most projects are setup with a quota of 10 deployed machines; not returning them when done, would mean your jobs get put into a queue that isnt clearing out in a rush.</p>
<p>One way to work around this would be to split the machine request and machine return functions into a pre-build and post-build step, and then pass over the session-id for the deployed machines via the build steps. That way, you could trap and report specific conditions. A varioation of this would be to setup conditional build steps, and have them execute different functions as needed.</p>
<p>An easy and simple workaround however, is to just wrap the test commands in a /usr/bin/timeout call. timeout is delivered as a binary from the coreutils package on CentOS Linux 7 and would be available on all machines, including the jenkins worker instances. Take a look at <a href="https://github.com/almighty/almighty-jobs/blob/master/devtools-ci-index.yaml#L64">https://github.com/almighty/almighty-jobs/blob/master/devtools-ci-index.yaml#L64</a> for a quick example of how this would work in a JJB template. This way we can timeout on the job, and yet be able to return nodes or handle any other content we need, in the same ci job script. A script that then does not have or need any Jenkins specific content, making it possible to run from developer laptops or as child jobs on its own.</p>
<p>/usr/bin/timeout ( man 1 timeout ) also allows you to preserve the sub commands exit status, if you need to track and report different status from your ci jobs. And ofcourse, there are many other uses for /usr/bin/timeout as well!</p>
<p>&#8211; KB</p>Karanbir Singhhttp://www.karan.org/blogKaranbir Singh :: Thinkability @karan.orgWake up sleepyhead...http://www.karan.org/blog/feed/2016-11-10T15:11:27+00:00(ab)using Alias for Zabbixtag:arrfab.net,2016-10-21:posts/2016/Oct/21/abusing-alias-for-zabbix/2016-10-20T22:00:00+00:00<p>It's not a secret that we use Zabbix to monitor the CentOS.org infra. That's even a reason why we (re)build it for some other architectures, including aarch64,ppc64,ppc64le on <a href="https://cbs.centos.org/koji/packageinfo?packageID=15">CBS</a> and also <a href="http://armv7.dev.centos.org/repodir/c7-extras-1/zabbix/">armhfp</a></p>
<p>There are really cool things in Zabbix, including <a href="https://www.zabbix.com/documentation/3.0/manual/discovery/low_level_discovery">Low-Level Discovery</a>. With such discovery, you can create items/prototypes/triggers that will be applied "automagically" for each discovered network interface, or mounted filesystem. For example, the default template (if you still use it) has such item prototypes and also graph for each discovered network interface and show you the bandwidth usage on those network interfaces.</p>
<p>But what happens if you suddenly want to for example to create some <a href="https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/calculated">calculated item</a> on top of those ? Well, the issue is that from one node to the other, interface name can be eth0, or sometimes eth1, and with CentOS 7 things started to also move to the new naming scheme, so you can have something like enp4s0f0. I wanted to create a template that would fit-them-all, so I had a look at calculated item and thought "well, easy : let's have that calculated item use a user macro that would define the name of the interface we really want to gather stats from ..." .. but it seems I was wrong. Zabbix <a href="https://www.zabbix.com/documentation/3.0/manual/config/macros/usermacros">user macros</a> can be used in multiple places, but not <a href="https://support.zabbix.com/browse/ZBX-11373">everywhere</a>. (It seems that I wasn't the only one not understanding the doc coverage for this, but at least that bug report will have an effect on the doc to clarify this)</p>
<p>That's when I discussed this in #zabbix (on irc.freenode.net) that <a href="https://twitter.com/real_richlv">RichLV</a> pointed me to something that could be interesting for my case : <a href="https://www.zabbix.com/documentation/3.0/manual/appendix/config/zabbix_agentd">Alias</a>. I must admit that it's the first time I was hearing about it, and I don't even know when it landed in Zabbix (or if I just overlooked it at first sight).</p>
<p>So cool, now I can just have our config mgmt pushing for example a /etc/zabbix/zabbix_agentd.d/interface-alias.conf file that looks like this and reload zabbix-agent : </p>
<div class="highlight"><pre>Alias=net.if.default.out:net.if.out[enp4s0f0]
Alias=net.if.default.in:net.if.in[enp4s0f0]
</pre></div>
<p>That means that now, whatever the interface name will be (as puppet in our case will create that file for us) , we'll be able to get values from net.if.default.out and net.if.default.in keys, automatically. Cool</p>
<p>That also means that if you want to aggregate all this into a single key for a group of nodes (and so graph that too), you can do something always referencing those new keys (example for the total outgoing bandwidth for a group of hosts) :</p>
<div class="highlight"><pre>grpsum[&quot;Your group name&quot;,&quot;net.if.default.out&quot;,last,0]
</pre></div>
<p>And from that point, you can easily also configure triggers, and graphs too.
Now going back to work on some other calculated items for total bandwith usage for a period of time and triggers based on some max_bw_usage user macro.</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00New CentOS Atomic Host with Optional Docker 1.12https://seven.centos.org/?p=7542016-10-11T22:17:00+00:00<p>An updated version of CentOS Atomic Host (tree version 7.20161006), is <a href="https://wiki.centos.org/SpecialInterestGroup/Atomic/Download">now available</a>, featuring the option of substituting the host&#8217;s default docker 1.10 container engine with a more recent, docker 1.12-based version, provided via the docker-latest package.</p>
<p>CentOS Atomic Host is a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.</p>
<p>CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. These images are available for download at <a href="http://cloud.centos.org/centos/7/atomic/images/">cloud.centos.org</a>. The backing ostree repo is published to <a href="http://mirror.centos.org/centos/7/atomic/x86_64/repo">mirror.centos.org</a>.</p>
<p>CentOS Atomic Host includes these core component versions:</p>
<ul>
<li>atomic-1.10.5-7.el7.x86_64</li>
<li>cloud-init-0.7.5-10.el7.centos.1.x86_64</li>
<li>docker-1.10.3-46.el7.centos.14.x86_64</li>
<li>etcd-2.3.7-4.el7.x86_64</li>
<li>flannel-0.5.3-9.el7.x86_64</li>
<li>kernel-3.10.0-327.36.1.el7.x86_64</li>
<li>kubernetes-1.2.0-0.13.gitec7364b.el7.x86_64</li>
<li>ostree-2016.7-2.atomic.el7.x86_64</li>
</ul>
<h2 id="docker-latest">docker-latest</h2>
<p>You can switch to the alternate docker version by running:</p>
<pre id="systemctl-disable-docker---now"># systemctl disable docker --now
# systemctl enable docker-latest --now
# sed -i '/DOCKERBINARY/s/^#//g' /etc/sysconfig/docker</pre>
<p>Because both docker services share the /run/docker directory, you cannot run both docker and docker-latest at the same time on the same system.</p>
<h2 id="upgrading">Upgrading</h2>
<p>If you&#8217;re running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:</p>
<pre>$ sudo atomic host upgrade</pre>
<h2 id="images">Images</h2>
<h3 id="vagrant">Vagrant</h3>
<p><a href="http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Vagrant-Libvirt.box">CentOS-Atomic-Host-7-Vagrant-Libvirt.box</a> (546 MB) and <a href="http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Vagrant-Virtualbox.box">CentOS-Atomic-Host-7-Vagrant-Virtualbox.box</a> (558 MB) are Vagrant boxes for Libvirt and Virtualbox providers.</p>
<p>The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see <a href="https://atlas.hashicorp.com/centos/boxes/atomic-host">https://atlas.hashicorp.com/centos/boxes/atomic-host</a>). For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed:</p>
<pre>$ vagrant init centos/atomic-host &amp;&amp; vagrant up --provider virtualbox</pre>
<h3 id="iso">ISO</h3>
<p>The <a href="http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Installer.iso">installer ISO</a> (776 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This image allows users to control the install using kickstarts and to define custom storage, networking and user accounts. This is the recommended option for getting CentOS Atomic Host onto bare metal machines, or for generating your own image sets for custom environments.</p>
<h3 id="qcow2">QCOW2</h3>
<p>The <a href="http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-GenericCloud.qcow2">CentOS-Atomic-Host-7-GenericCloud.qcow2</a> (1.2 GB) image is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can <a href="http://www.projectatomic.io/blog/2014/10/getting-started-with-cloud-init/">create your own</a> NoCloud iso image.</p>
<h3 id="amazon-machine-images">Amazon Machine Images</h3>
<pre>Region Image ID
------ --------
ap-northeast-1 ami-494e9628
ap-northeast-2 ami-07bb6f69
ap-southeast-1 ami-60b51203
ap-southeast-2 ami-598cbf3a
eu-central-1 ami-6350af0c
eu-west-1 ami-8c2c6fff
sa-east-1 ami-5a51c336
us-east-1 ami-cfeca0d8
us-west-1 ami-71bef711
us-west-2 ami-f020f890</pre>
<h3 id="sha-sums">SHA Sums</h3>
<pre>3af63166dd86c0b719efb57b5b4cc0997b959caa6680d3f86ff710bc382a2bd6 CentOS-Atomic-Host-7.1609-GenericCloud.qcow2
4ab6c62710cf81ae1e632c428a915648e3573adddab9f9c5d6fed517dcf27553 CentOS-Atomic-Host-7.1609-GenericCloud.qcow2.gz
06549195aa626b82f9b7473a366a7f1b32932dff60e8d53be924b3b0c2635e00 CentOS-Atomic-Host-7.1609-GenericCloud.qcow2.xz
e26651dd1c3dde5b6dfee088876189fb29fb79f729e86fcd516fe87ccd992381 CentOS-Atomic-Host-7.1609-Installer.iso
037dad130293cf7476e9d711fec0d40d88f370f36dae66b80c8cce4ab5082fc2 CentOS-Atomic-Host-7.1609-Vagrant-Libvirt.box
1353920c87b0516c44072a184bbb8845c89ba1e538185a4dfc03076f65401dca CentOS-Atomic-Host-7.1609-Vagrant-VirtualBox.box</pre>
<h2 id="release-cycle">Release Cycle</h2>
<p>The CentOS Atomic Host image follows the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they&#8217;re rebuilt and included in new images. After the images are tested by the SIG and deemed ready, we announce them.</p>
<h2 id="getting-involved">Getting Involved</h2>
<p>CentOS Atomic Host is produced by the <a href="http://wiki.centos.org/SpecialInterestGroup/Atomic">CentOS Atomic SIG</a>, based on upstream work from <a href="http://www.projectatomic.io/">Project Atomic</a>. If you&#8217;d like to work on testing images, help with packaging, documentation &#8212; join us!</p>
<p>The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you&#8217;ll often find us in #atomic and/or #centos-devel if you have questions. You can also join the <a href="https://lists.projectatomic.io/mailman/listinfo/atomic-devel">atomic-devel</a> mailing list if you&#8217;d like to discuss the direction of Project Atomic, its components, or have other questions.</p>
<h2 id="getting-help">Getting Help</h2>
<p>If you run into any problems with the images or components, feel free to ask on the <a href="http://lists.centos.org/mailman/listinfo/centos-devel">centos-devel</a> mailing list. Have questions about using Atomic? See the <a href="https://lists.projectatomic.io/mailman/listinfo/atomic">atomic</a> mailing list or find us in the #atomic channel on Freenode.</p>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00Updated CentOS Vagrant Images Available (v1609.01)https://seven.centos.org/?p=7372016-10-06T22:07:30+00:00<p>Official Vagrant images for CentOS Linux 6 and CentOS Linux 7 for x86_64 are now available for download, featuring updated packages to 30 September 2016, as well as the following user-visible changes:</p>
<ul>
<li>the <em>centos/7</em> image now uses the XFS filesystem, which is the default filesystem when installing CentOS Linux 7 from the official DVD images</li>
<li>fixed <a href="https://github.com/CentOS/sig-cloud-instance-build/issues/73">issue #73</a> (VMware Tools installation unable to complete successfully due to a dracut configuration problem)</li>
</ul>
<h3>Known Issues</h3>
<ol>
<li>The VirtualBox Guest Additions are not preinstalled; if you need them for shared folders, please install the <a href="https://github.com/dotless-de/vagrant-vbguest">vagrant-vbguest</a> plugin. We recommend <a href="https://www.vagrantup.com/docs/synced-folders/nfs.html">using NFS</a> instead of VirtualBox shared folders if possible.</li>
<li>Since the Guest Additions are missing, our images are preconfigured to use rsync for synced folders. Windows users can either use SMB for synced folders, or disable the sync directory by adding the line
<pre>config.vm.synced_folder ".", "/vagrant", disabled: true</pre>
<p>to your Vagrantfile.</p></li>
<li>Vagrant 1.8.5 is unable to create new Linux boxes due to <a href="https://github.com/mitchellh/vagrant/issues/7610">Vagrant bug #7610</a>. Please upgrade to Vagrant 1.8.6.</li>
<li>Installing <em>open-vm-tools</em> is not enough for enabling shared folders with Vagrant&#8217;s VMware provider. Please follow the detailed instructions in <a href="https://github.com/mvermaes/centos-vmware-tools">https://github.com/mvermaes/centos-vmware-tools</a>.</li>
<li><strong>[security]</strong>: Any new user accounts that you create can gain root privileges via <code>su - root</code> or <code>su - vagrant</code>.</li>
</ol>
<h3>Downloads</h3>
<p>The official images can be downloaded from Hashicorp’s Atlas. We provide <a href="https://atlas.hashicorp.com/centos/">images</a> for libvirt-kvm, VirtualBox and VMware.</p>
<p>If you never used our images before:</p>
<pre>$ vagrant box add centos/6 # for CentOS Linux 6
$ vagrant box add centos/7 # for CentOS Linux 7
</pre>
<p>Existing users can upgrade their images:</p>
<pre>$ vagrant box update --box centos/6
$ vagrant box update --box centos/7</pre>
<h3>Verifying the integrity of the images</h3>
<p>The SHA256 checksums of the images are signed with the CentOS 7 Official Signing Key. First, download and verify the checksum file:</p>
<pre>$ curl http://cloud.centos.org/centos/7/vagrant/x86_64/images/sha256sum.txt.asc -o sha256sum.txt.asc
$ gpg --verify sha256sum.txt.asc
</pre>
<p>If the check passed, you can use the corresponding checksum when downloading the image with Vagrant:</p>
<pre>$ vagrant box add --checksum-type sha256 --checksum 3c35dc1945fff00c2dddc40a05d7ccf1026b70cfa31a8ba0cc018c5001b22699 --provider libvirt --box-version 1609.01 centos/7
</pre>
<p>Unfortunately, this is not possible with <code>vagrant box update</code>.</p>
<h3>Feedback</h3>
<p>If you encounter any unexpected issues with the Vagrant images, feel free to ask on the <a href="http://lists.centos.org/mailman/listinfo/centos-devel">centos-devel</a> mailing list, or via IRC, in #centos on Freenode.</p>
<h3>Ackowledgements</h3>
<p>We would like to thank the following people (in alphabetical order):</p>
<ul>
<li>Graham Mainwaring, for helping with tests and validations</li>
<li>Rafal Skolasinski, for reporting the <i>su</i> issue
<li>Michael Vermaes, for testing our official images, as well as for writing the detailed guide to using them with VMware Fusion Pro and VMware Workstation Pro.</li>
</li></ul>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00CentOS-7 1609 Rolling ISOs Now Livetag:blogger.com,1999:blog-7607366660500015746.post-1429170019908823122016-10-01T07:01:08+00:00<h2><span>Rolling ISOs</span></h2>The CentOS Linux team produces rolling CentOS-7 isos, normally on a monthly basis.<br /><br />The most recently completed version of those ISOs are version <b>1609</b> (<b>16</b> is for 2016, <b>09</b> is for September).<br /><br />The team usually creates all our ISO and cloud images based on all updates through the 28th of the month in question .. so <b>1609</b> would mean these ISOs will contain all updates for CentOS-7 through September 28th, 2016.<br /><br />These rolling ISOs have the same installer as the most recent CentOS-7 point release (currently 7.2.1511) so that they install on the same hardware as our original ISOs, while the packages installed are the latest updates.<br /><br />This means that the actual kernel that boots up on the ISO is the 7.2.1511 default kernel (kernel-3.10.0-327.el7.x86_64.rpm), but that the kernel installed is the latest kernel package (kernel-3.10.0-327.36.1.el7.x86_64.rpm for the 1609 ISOs).<br /><br />These normal Rolling ISOs can be downloaded from this <a href="http://buildlogs.centos.org/rolling/7/isos/x86_64/" target="_blank"><b>LINK</b></a> and here are the sha256sums:<br /><span><b><a href="http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-DVD-1609-01.iso" target="_blank">CentOS-7-x86_64-DVD-1609-01.iso</a>:</b></span><br /><span>3948f7a31a8693b2df90dc31252551dcd5aa9d13f4910ad9ce28fcddc247d84f&nbsp; </span><br /><span><br /></span><b><span><a href="http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Everything-1609-01.iso" target="_blank">CentOS-7-x86_64-Everything-1609-01.iso</a>:</span></b><br /><span>602383c2aa93f6d7df46bd47658dcbf9b9d567108dec56ba60ce46a2f51c6eb2&nbsp; </span><br /><span><br /><b><a href="http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-LiveGNOME-1609-01.iso" target="_blank">CentOS-7-x86_64-LiveGNOME-1609-01.iso</a>:</b></span><br /><span>f6ee8af6814bc58e2c8424db862a443649f3a57b5f85caf63704ab52d5bbac68&nbsp; </span><br /><span><br /></span><span><b><a href="http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-LiveKDE-1609-01.iso" target="_blank">CentOS-7-x86_64-LiveKDE-1609-01.iso</a>:</b><br />1349c70e815d46c49d6ea459de6fbc074f5131c803343db18d32987ee78fd303&nbsp; </span><br /><span><br /></span><span><b><a href="http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Minimal-1609-01.iso" target="_blank">CentOS-7-x86_64-Minimal-1609-01.iso</a>:</b><br />54721e5e444a3191b18b0fabe1c35e12b65f93aa31732beb7899212d19cab69b&nbsp; </span><br /><br />You can verify the sha256sum of your downloaded ISO following these <a href="https://wiki.centos.org/TipsAndTricks/sha256sum" target="_blank"><b>instructions</b></a> prior to install.<br /><br />The <b>DVD</b> ISO contains everything needed to do an install, but still fits on one 4.3 GB DVD.&nbsp; This is the most versatile install that will fit on a single DVD and if you are new to CentOS this likely the installer you want.&nbsp; If you pick Minimum Install in this installer, you can do an install that is identical to Minimal ISO.&nbsp; You can also install many different Workstation and Server installs from this ISO, including both GNOME and KDE. <br /><br />The <b>Everything</b> ISO has all packages, even those not used by the installer.&nbsp; You usually do not need this ISO unless you do not have access to the internet and want to install things later from this DVD and not included by the graphical installer.&nbsp; <b>Most users will not need this ISO</b>, it is &gt; 7 GB but can do installs from a USB key that is big enough to hold it (currently an 8 GB key).<br /><br />The <b>LiveGNOME</b> ISO is a Basic GNOME Workstation install, but there is no modification or personalization allowed during the install.&nbsp; It is a much easier install to do, but any extras packages must be installed from the internet later.<br /><br />The <b>LiveKDE</b> ISO is Basic KDE Workstation install.&nbsp; It also does not allow modification or personalization until after the install has finished.<br /><br />The <b>Minimal</b> ISO is a very small and quick install that boots to the command console and has network connectivity and a firewall.&nbsp; It is used by System Administrators for the minimal install that they can then add functionality to.&nbsp; You need to know what you are doing to use this ISO. <br /><br /><h2><span>Newer Hardware Support</span></h2>As explained above, the normal rolling ISOs boot from the Point Release installer.&nbsp; Sometimes there is newer hardware that might not be supported in the point release installer, but could be supported with a newer kernel.&nbsp; This installer is much less tested and is only recommended if you can not get one of the normal installers to work for you.<br /><br />There are only 2 ISOs in this family, here are the links and sha256sums:<br /><pre></pre><span><span><a href="http://buildlogs.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1609-99.iso" target="_blank"><b>CentOS-7-x86_64-DVD-1609-99.iso</b></a>:</span></span><br /><span><span>90c7148ddccbb278d45d06805dee6599ec1acc585cafd02d56c6b8e32a238fa9&nbsp;</span></span><br /><span><span><br /></span></span><b><span><span><a href="http://buildlogs.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1609-99.iso" target="_blank">CentOS-7-x86_64-Minimal-1609-99.iso</a>:</span></span></b><br /><span><span>1cfbbc73cc7a0eb17d7fe2fa5b1adf07492e340540603e8e1fd28b52e95f02e3</span></span><br /><span><br /></span><span>You can verify the ISO's sha256 sum using this <a href="https://wiki.centos.org/TipsAndTricks/sha256sum" target="_blank"><b>LINK</b></a>, and the descriptions above are the same for these two ISOs.</span><br /><br /><br /><pre></pre>Johnny Hughesnoreply@blogger.comhttp://centosnow.blogspot.com/CentOS Nowtag:blogger.com,1999:blog-76073666605000157462016-12-10T02:30:04+00:00CentOS Infra public service dashboardtag:arrfab.net,2016-09-22:posts/2016/Sep/22/centos-infra-public-service-dashboard/2016-09-21T22:00:00+00:00<p>As soon as you're running some IT services, there is one thing that you already know : you'll have <a href="https://en.wikipedia.org/wiki/Downtime">downtimes</a>, despite all your efforts to avoid those...</p>
<p>As the old joke says : <code>"What's up ?" asked the Boss. "Hopefully everything !" answered the SysAdmin guy ....</code></p>
<p>You probably know that the CentOS infra is itself widespread, and subject to quick move too. Recently we had to <a href="https://lists.centos.org/pipermail/centos-announce/2016-September/022065.html">announce</a> an important DC relocation that impacts some of our crucial and publicly facing services. That one falls in the "scheduled and known outages" category, and can be prepared. For such "downtime" we always announced that through several mediums, like sending a mail to the centos-announce, centos-devel (and in this case , also to the ci-users) <a href="https://lists.centos.org">mailing lists</a>. But even when we announce that in advance, some people forget about it, or people using (sometimes "indirectly") the concerned service are surprized and then ask about it (usually in #centos or #centos-devel on irc.freenode.net).</p>
<p>In parallel to those "scheduled outages", we have also the worst ones : the unscheduled ones. For those ones, depending on the impact/criticity of the impacted service, and also the estimated <a href="https://en.wikipedia.org/wiki/Recovery_time_objective">RTO</a>, we also send a mail to the concerned mailing lists (or not).</p>
<p>So we just decided to show a very simple and public dashboard for the CentOS Infra, but only covering the publicly facing services, to have a quick overview of that part of the Infra. It's now live and hosted on <a href="https://status.centos.org">https://status.centos.org</a>.</p>
<p>We use <a href="http://www.zabbix.com">Zabbix</a> to monitor our Infra (so we build it for multiple arches, like x86_64,i386,ppc64,ppc64le,aarch64 and also armhfp) , including through remote zabbix <a href="https://www.zabbix.com/documentation/3.0/manual/concepts/proxy">proxies</a> (because of our "distributed" network setup right now, with machines all around the world).
For some of those services listed on status.centos.org, we can "manually" announce a downtime/maintenance period, but Zabbix also updates on its own that dashboard.
The simple way to link those together was to use zabbix <a href="https://www.zabbix.com/documentation/3.0/manual/config/notifications/media/script">custom alertscripts</a> and you can even customize those to send specific <a href="https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location">macros</a> and have that alertscript just parsing and then updating the dashboard.</p>
<p>We hope to enhance that dashboard in the future, but it's a good start, and I have to thank again <a href="https://twitter.com/puiterwijkFP">Patrick Uiterwijk</a> who wrote that <a href="https://git.fedorahosted.org/git/fedora-status">tool</a> for Fedora initially (and that we adapted to our needs).</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Community Infrastructure Maintenance Window: Oct-10-2016https://seven.centos.org/?p=7272016-09-20T04:41:40+00:00<p>The CentOS Infrastructure team will be moving the machines hosting cbs.centos.org, ci.centos.org and accounts.centos.org on October 10th, 2016. We expect a downtime of 48hrs. Contact us in #centos-devel on freenode at any time during that period for questions, or watch the <a href="https://lists.centos.org/mailman/listinfo/centos-devel">centos-devel</a> mailing list for the latest updates.</p>
<p>The servers, switches, PDUs, and even the racks themselves hosting <a href="https://cbs.centos.org">CBS</a>, <a href="https://ci.centos.org">ci.centos.org</a>, <a href="https://accounts.centos.org">accounts.centos.org</a> and registry.centos.org are all stored in a datacenter in Raleigh, North Carolina, USA and will be moved to a new space in the datacenter on Monday October 10th. This new space provides a little bit of expansion room for the future of these services and consolidates networks that were previously separate (namely the CICO cloud with the rest of the CI infrastructure). During this window, all services related to the listed CentOS properties will be down.</p>
<p>We blocked out 2 days (48hrs) to do the move, but we will do our best to restore services as soon as it is possible to do so.</p>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00Updated CentOS Vagrant Images Available (v1608.01)https://seven.centos.org/?p=7102016-09-07T23:42:37+00:00<p><em>UPDATE 2016-09-08: Due to additional checks, we had to retire v1608.01 from Atlas and release it again as v1608.02. The two versions are identical.</em></p>
<p>Official Vagrant images for CentOS Linux 6 and CentOS Linux 7 for x86_64 are now available for download, featuring updated packages to 31 August 2016, as well as a new image for VMware Fusion.</p>
<h3>Known Issues</h3>
<ol>
<li>The VirtualBox Guest Additions are not preinstalled; if you need them for shared folders, please install the <a href="https://github.com/dotless-de/vagrant-vbguest">vagrant-vbguest</a> plugin. We recommend <a href="https://www.vagrantup.com/docs/synced-folders/nfs.html">using NFS</a> instead of VirtualBox shared folders if possible.</li>
<li>Since the Guest Additions are missing, our images are preconfigured to use rsync for synced folders. Windows users can either use SMB for synced folders, or disable the sync directory by adding the line <code>config.vm.synced_folder ".", "/vagrant", disabled: true</code> to the Vagrantfile.</li>
<li>Vagrant 1.8.5 is unable to create new Linux boxes due to <a href="https://github.com/mitchellh/vagrant/issues/7610">Vagrant bug #7610</a>. You can use <a href="https://releases.hashicorp.com/vagrant/1.8.4/">Vagrant 1.8.4</a> until version 1.8.6 is released.</li>
<li>The VMware Tools installer <a href="https://github.com/CentOS/sig-cloud-instance-build/issues/73">fails to generate a new initramfs</a> due to a dracut configuration error in both our image and VMware Tools. As a workaround, change the <em>add_drivers</em> line in <em>/etc/dracut.conf.d/vmware-fusion-drivers.conf</em> to
<pre>add_drivers+=" mptspi "</pre>
<p> (add spaces directly before and after <em>mptspi</em>) before trying to install VMware Tools or open-vm-tools.</p></li></ol>
<h3>Downloads</h3>
<p>The official images can be downloaded from Hashicorp&#8217;s Atlas. We provide <a href="https://atlas.hashicorp.com/centos/">images</a> for libvirt, VirtualBox and VMware.</p>
<p>If you never used our images before:</p>
<pre>$ vagrant box add centos/6 # for CentOS Linux 6
$ vagrant box add centos/7 # for CentOS Linux 7
</pre>
<p>Existing users can upgrade their images by:</p>
<pre>$ vagrant box update --box centos/6
$ vagrant box update --box centos/7
</pre>
<h3>Checksums</h3>
<p>The downloaded images should have the following SHA256 checksums:</p>
<pre>
914ab02db12f2d19f71dbd3c6cb171dff683893443e26f2f03160491945366dc CentOS-6-x86_64-Vagrant-1608_01.LibVirt.box
5391ea7bdafafe8d8df58b8405d81cafdcd0b8273c18cdd37133dcf1cb329a0b CentOS-6-x86_64-Vagrant-1608_01.VirtualBox.box
4d6a5906ada93a5228f62671f7c97bed0ae3c961df108c25ceee278a8d9d17d2 CentOS-6-x86_64-Vagrant-1608_01.VMwareFusion.box
2916442968486a41315cb93d35fbbaeaf72e200f051f4996b5766649b8c3a325 CentOS-7-x86_64-Vagrant-1608_01.LibVirt.box
415b79487cdb7e0246ef93585de08d2063b1e7b85ff5666f60de5cb96a4a027c CentOS-7-x86_64-Vagrant-1608_01.VirtualBox.box
44d26155e89fa5d74994167489bd66da4187b3da02ac3a063f0b26cfab965baf CentOS-7-x86_64-Vagrant-1608_01.VMwareFusion.box
</pre>
<p>Vagrant has the ability to verify that the downloaded image has a specific checksum, e.g.</p>
<pre>
$ vagrant box add --checksum-type sha256 --checksum 2916442968486a41315cb93d35fbbaeaf72e200f051f4996b5766649b8c3a325 --provider libvirt centos/7
</pre>
<p>Unfortunately, this is not possible with <code>vagrant box update</code>.</p>
<h3>Feedback</h3>
<p>If you encounter any unexpected issues with the Vagrant images, feel free to ask on the <a href="http://lists.centos.org/mailman/listinfo/centos-devel">centos-devel</a> mailing list, or in #centos-devel on Freenode.</p>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00Continuous integration tests for the CentOS Vagrant imageshttps://seven.centos.org/?p=6912016-09-01T14:43:58+00:00<p>Since yesterday, we have production-ready automated tests for our Vagrant images on <a href="https://ci.centos.org">ci.centos.org</a>, fully integrated with GitHub. We were only able to build and test scratch images manually until now, which was time consuming and had the disadvantage that, due to hardware limitations on my side, only the images for VirtualBox were actually tested.</p>
<p>A pull request to the <a href="https://github.com/CentOS/sig-cloud-instance-build">CentOS/sig-cloud-instance-build</a> repository on GitHub will trigger the <a href="https://ci.centos.org/job/cloudinstance-vagrant-build/">cloudinstance-vagrant-build</a> Jenkins job on ci.centos.org, which builds all Vagrant images in <abbr title="Community Buildsystem">CBS</abbr>. If the build process completes without errors, the <a href="https://ci.centos.org/job/cloudinstance-vagrant-test/">cloudinstance-vagrant-test</a> job will test the Vagrant images for both CentOS Linux 6 and CentOS Linux 7, using the libvirt and virtualbox Vagrant providers. If everything is ok, you can see the test result directly below the pull request on GitHub (please note that a full test currently needs almost two hours to complete, most of the time being spent building the images):</p>
<p><a href="https://seven.centos.org/wp-content/uploads/2016/09/github-fs8.png"><img src="https://seven.centos.org/wp-content/uploads/2016/09/github-fs8.png" alt="Screenshot of a successful test, taken on GitHub" width="775" height="167" class="alignnone size-full wp-image-698" /></a></p>
<p>Most of the code for the test is in my <a href="https://github.com/lpancescu/cloudinstance-vagrant-cico-util">cloudinstance-vagrant-cico-util</a> repository on GitHub, with a few additional snippets in the Jenkins configuration for each job. We are using the latest Vagrant provided by the <a href="https://wiki.centos.org/SpecialInterestGroup/SCLo">Software Collections SIG</a>, and VirtualBox 5.0.26 from <a href="https://www.virtualbox.org">virtualbox.org</a> (at the time of writing this post, Vagrant refuses to start if it detects VirtualBox 5.1). Feedback is of course welcome.</p>CentOS Seven bloghttps://seven.centos.orgSeven.CentOS.orgNews, views and reports on CentOS-7https://seven.centos.org/feed/2016-11-22T13:30:05+00:00CentOS at cPanel 2016tag:blogger.com,1999:blog-7607366660500015746.post-50362223767643955282016-08-15T10:23:17+00:00The CentOS team will have a booth at the&nbsp;<a href="http://conference16.cpanel.com/" target="_blank"><b>cPanel 2016 WEIRED Conference</b></a> in Portland, Oregon at the&nbsp;Hilton Portland &amp; Executive Tower on <b>October 3rd through the 5th 2016</b>.<br /><br />I (Johnny Hughes) will be there to discuss all things CentOS and we may have some guests at the booth from some of our Special Interest Groups and others from the CentOS Community.<br /><br />If you are planning to be at the conference, please stop by and see us.Johnny Hughesnoreply@blogger.comhttp://centosnow.blogspot.com/CentOS Nowtag:blogger.com,1999:blog-76073666605000157462016-12-10T02:30:04+00:00CentOS at 2016 Texas Linux Festtag:blogger.com,1999:blog-7607366660500015746.post-3619314007881131282016-06-21T18:25:32+00:00We will have a CentOS Booth at the <a href="http://2016.texaslinuxfest.org/" target="_blank"><b>2016 Texas Linux Fest</b></a> on <b>July 8th and 9th</b> in the <b><a href="https://www.google.com/maps/place/Austin+Convention+Center/@30.2635686,-97.7396059,15z/data=!4m5!3m4!1s0x0:0x3041433e6e0a9355!8m2!3d30.2635686!4d-97.7396059" target="_blank">Austin Texas Convention Center</a></b>.<br /><br />Please stop by the CentOS booth for some Swag and discussion.<br /><br />We will also have several operational CentOS-7 Arm32 devices at the booth, including a <a href="https://www.raspberrypi.org/products/raspberry-pi-2-model-b/" target="_blank"><b>Raspberry Pi2</b></a>, <a href="https://www.raspberrypi.org/products/raspberry-pi-3-model-b/" target="_blank"><b>Raspberry Pi3</b></a>, <a href="https://en.wikipedia.org/wiki/Cubieboard#Cubietruck_.28Cubieboard3.29" target="_blank"><b>CubieTruck</b></a> (Cubieboard3) and <a href="https://en.wikipedia.org/wiki/Cubieboard#Cubietruck_Plus_.28Cubieboard5.29" target="_blank"><b>CubieTruck Plus</b></a> (Cubieboard5).&nbsp; These devices are showcasing our <a href="https://wiki.centos.org/SpecialInterestGroup/AltArch" target="_blank"><b>AltArch Special Interest Group</b></a>, which produce ppc64, ppc64le, armhfp (Arm32), aarch64 Arm64), and i686 (x86 32) architectures of CentOS-7.<br /><br />We also will be glad to discuss the new things happening within the project, including a number of operational Special Interest Groups (SIGs) that are producing add on software for CentOS including The Xen Hypervisor, OpenStack (via RDO), Storage (GlusterFS and Ceph), Software Collections, Cloud Images (AWS, Azure, Oracle, Vagrant Boxes, KVM), Containers (Docker and Project Atomic).<br /><br />So, if you have been using CentOS for the past 12 years, all that is happening just like it always has (long lived standard Linux distro with LTS), as well as all the new hypervisor, container and cloud capabilities.Johnny Hughesnoreply@blogger.comhttp://centosnow.blogspot.com/CentOS Nowtag:blogger.com,1999:blog-76073666605000157462016-12-10T02:30:04+00:00Generating multiple certificates with Letsencrypt from a single instancetag:arrfab.net,2016-05-03:posts/2016/May/03/generating-multiple-certificates-with-letsencrypt-from-a-single-instance/2016-05-02T22:00:00+00:00<p>Recently I was discussing with some people about TLS everywhere, and we then started to discuss about the <a href="https://letsencrypt.org/">Letsencrypt</a> initiative.
I had to admit that I just tested it some time ago (just for "fun") but I suddenly looked at it from a different angle : while the most used case is when you install/run the letsencrypt client on your node to directly configure it, I have to admit that it's something I didn't want to have to deal with. I still think that proper web server configuration has to happen through cfgmgmt, and not through another process. (and same for the key/cert distribution, something for a different blog post maybe).</p>
<p>If so you're (pushing|pulling) automatically your web servers configuration from $cfgmgmt, but that you want to use/deploy TLS certificates signed by letsencrypt, what can you do ? Well, the good news is that you don't have to be forced to let the letsencrypt client touch your configuration at all : you can use the "certonly" option to just generate the private key locally, send the <a href="https://en.wikipedia.org/wiki/Certificate_signing_request">csr</a> and get the signed cert back (and the whole chain too)
One thing to know about letsencrypt is that the validation/verification process isn't the one that you can see in most of the companies providing CA/signing capabilities : as there is no ID/Paper verification (or something else) , the only validation for the domain/sub-domain that you want to generate a certificate for happens over http request (basically creating a file with a challenge , process a request from their "ACME" server[s] to retrieve that file back, and validate content)</p>
<p>So what are our options then ? The letsencrypt documentation mentions several <a href="http://letsencrypt.readthedocs.io/en/latest/using.html#plugins">plugins</a> like manual (involves you to then create the file with the challenge answer to the webserver, then launching the validation process) , or standalone (doesn't work if you already have a httpd/nginx process as there will be a port conflict) , or even webroot (working fine as it will then just write the file itself under /.well-kwown/ under the DocumentRoot)</p>
<p>The webroot seems easy, but as said, we don't want to even install letsencrypt on the web server[s]. Even worse, suppose (and that's the case I had in mind) that you have multiple web nodes configured in a kind of <a href="https://en.wikipedia.org/wiki/Content_delivery_network">CDN</a> way : you don't want to distribute that file on all the nodes for validation/verification (when using the "manual" plugin) and you'd have to do it on <em>all</em> the nodes (as you don't know in advance which one will be verified by the ACME server)</p>
<p>So what about something centralized (where you'd run the letsencrypt client locally) for all your certs (including some with <a href="https://en.wikipedia.org/wiki/SubjectAltName">SANs</a> ) in a transpartent way ? I so thought about something like this :</p>
<p><img alt="Single Letsencrypt node" src="https://arrfab.net/images/central-le-process.png" title="central letsencrypt node" /></p>
<p>The idea would be to :</p>
<ul>
<li>use a central node : let's call it central.domain.com (vm, docker container, make-your-choice-here) to launch the letsencrypt client</li>
<li>have the ACME server hitting transparently one of the web servers without any changed/uploaded file</li>
<li>the server getting the GET request for that file using the letsencrypt central node as a backend node</li>
<li>ACME server being happy and so signed certificates being available automatically on the centralize letsencrypt node.</li>
</ul>
<p>The good news is that it's possible and even really easy to implement, through <a href="https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass">ProxyPass</a> (for httpd/Apache web server) or <a href="http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass">proxy_pass</a> (for nginx based setup)</p>
<p>For example, for the httpd vhost config for sub1.domain.com (three nodes in our example) we can just add this in the .conf file :</p>
<div class="highlight"><pre><span class="nt">&lt;Location</span> <span class="err">&quot;/.well-known/&quot;</span><span class="nt">&gt;</span>
ProxyPass &quot;http://central.domain.com/.well-known/&quot;
<span class="nt">&lt;/Location&gt;</span>
</pre></div>
<p>So now, once in place everywhere, you can generate the cert for that domain on the central letsencrypt node (assuming that httpd is running on that node, and reachable from the "frontend" nodes, and that /var/www/html is indeed the DocumentRoot (default) for httpd on that node): </p>
<div class="highlight"><pre>letsencrypt certonly --webroot --webroot-path /var/www/html --manual-public-ip-logging-ok --agree-tos --email you@domain.com -d sub1.domain.com
</pre></div>
<p>Same if you run nginx instead (let's assume this for sub2.domain.com and sub3.domain.com) , you just have to add a snippet in your vhost .conf file (and before the / definition too): </p>
<div class="highlight"><pre><span class="nt">location</span> <span class="o">/</span><span class="nc">.well-known</span><span class="o">/</span> <span class="p">{</span>
<span class="n">proxy_pass</span> <span class="n">http</span><span class="o">://</span><span class="n">central</span><span class="o">.</span><span class="n">domain</span><span class="o">.</span><span class="n">com</span><span class="o">/.</span><span class="n">well</span><span class="o">-</span><span class="n">known</span><span class="o">/</span> <span class="p">;</span>
<span class="p">}</span>
</pre></div>
<p>And then on the central node, do the same thing, but you can add multiple -d for multiple SubjectAltName in the same cert :</p>
<div class="highlight"><pre>letsencrypt certonly --webroot --webroot-path /var/www/html --manual-public-ip-logging-ok --agree-tos --email you@domain.com -d sub2.domain.com -d sub3.domain.com
</pre></div>
<p>Transparent, smart, easy to do and even something you can deploy when you need to renew, and then remove to be back with initial config files too (if you don't want to have those ProxyPass directives active all the time)</p>
<p>The only thing you have also to know is that once you have proper TLS in place, it's usually better to redirect transpartently all requests to your http server to the https version. Most of the people will do that (next example for httpd/apache) like this : </p>
<div class="highlight"><pre> RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</pre></div>
<p>It's good, but when you'll renew the certificate, you'll probably just want to be sure that the GET request for /.well-known/* will continue to work over http (from the ACME server) so we can tune a little bit those rules (<a href="https://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritecond">RewriteCond</a> are cumulatives so it will not be redirect if url starts with .well-known: </p>
<div class="highlight"><pre> RewriteEngine On
RewriteCond $1 !^.well-known
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</pre></div>
<p>Different syntax, but same principle for nginx : (also snippet, not full configuration file for that server/vhost):</p>
<div class="highlight"><pre><span class="nt">location</span> <span class="o">/</span><span class="nc">.well-known</span><span class="o">/</span> <span class="p">{</span>
<span class="n">proxy_pass</span> <span class="n">http</span><span class="o">://</span><span class="n">central</span><span class="o">.</span><span class="n">domain</span><span class="o">.</span><span class="n">com</span><span class="o">/.</span><span class="n">well</span><span class="o">-</span><span class="n">known</span><span class="o">/</span> <span class="p">;</span>
<span class="p">}</span>
<span class="nt">location</span> <span class="o">/</span> <span class="p">{</span>
<span class="n">rewrite</span> <span class="o">^</span> <span class="n">https</span><span class="o">://</span><span class="err">$</span><span class="n">server_name</span><span class="err">$</span><span class="n">request_uri</span><span class="o">?</span> <span class="n">permanent</span><span class="p">;</span>
<span class="p">}</span>
</pre></div>
<p>Hope that you'll have found that useful, especially if you don't want to deploy letsencrypt everywhere but still use it to generate locally your keys/certs. Once done, you can then distribute/push/pull (depending on your cfgmgmt) those files and don't forget to also implement proper monitoring for cert validity and automation around that too (consider that your homework)</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00IPv6 connectivity status within the CentOS.org infratag:arrfab.net,2016-04-29:posts/2016/Apr/29/ipv6-connectivity-status-within-the-centosorg-infra/2016-04-28T22:00:00+00:00<p>Recently, some people started to ask proper IPv6/AAAA record for some of our public mirror infrastructure, like mirror.centos.org, and also <a href="https://wiki.centos.org/HowTos/CreatePublicMirrors">msync.centos.org</a> </p>
<p>Reason is that a lot of people are now using IPv6 wherever possible and from a CentOS point of view, we should ensure that everybody can have content over (legacy) ipv4 and ipv6. Funny that I call ipv4 "legacy" as we still have to admit that it's still the default everywhere, even in 2016 with the available pools now exhausted.</p>
<p>While we had already some AAAA records for some of our public nodes (like <a href="https://www.centos.org">www.centos.org</a> as an example), I started to "chase" after proper and native ipv6 connectivity for our nodes.
That's where I had to take contact with all our valuable <a href="https://www.centos.org/sponsors">sponsors</a>. First thing to say is that we'd like to thank them all for their support for the CentOS Project over the years : it wouldn't have been possible to deliver multiple terrabytes of data per month without their sponsorship !</p>
<p>WRT ipv6 connectivity that's where the results of my quest where really different : while some DCs support ipv6 natively, and even answer you in 5 minutes when asking for a /64 subnet to be allocated , some other aren't still ipv6 ready : For the worst case the answer was "nothing ready and no plan for that" or for sometimes the received answer was something like "it's on the roadmap for 2018/2019").</p>
<p>The good news is that ~30% of our nodes behind msync.centos.org have now ipv6 connectivity, so the next step is now to test our various configurations (distributed by puppet) and then also our GeoIP redirection (done at the <a href="http://www.powerdns.com">PowerDNS</a> level for such records, for which we'll also then add proper AAAA record)</p>
<p>Hopefully we'll have that tested and then announced soon, and also for other public services that we're providing to you.</p>
<p>Stay tuned for more info about ipv6 deployment within centos.org !</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00EPEL round table at FOSDEM 2016http://iquaid.org/?p=24382016-01-26T18:57:35+00:00<p>As a follow-up to last year&#8217;s literally-a-discussion-in-the-hallway about <a href="https://fedoraproject.org/wiki/EPEL">EPEL</a> with a few dozen folks at <a href="http://fosdem.org">FOSDEM</a> 2015, we&#8217;re doing a round table discussion with some of the same people and similar topics this Sunday at FOSDEM, <a href="https://fosdem.org/2016/schedule/event/whither_epel/">&#8220;Wither EPEL? Harvesting the next generation of software for the enterprise&#8221;</a> in the distro devroom. As a treat, <a href="https://fedoraproject.org/wiki/StephenSmoogen">Stephen Smoogen</a> will be moderating the panel; Smooge is not only a long-time Fedora and CentOS contributor, he is one of us who started EPEL a decade ago.</p>
<p>If you are an EPEL user (for whatever operating system), a packager, an upstream project member who wants to see your software in EPEL, a hardware enthusiast wanting to see builds for your favorite architecture, etc. &#8230; you are welcome to join us. We&#8217;ll have plenty of time for questions and issues from the audience.</p>
<p>The trick is that EPEL is useful or crucial for a number of the projects now releasing on top of CentOS via the special interest group process (<a href="https://wiki.centos.org/SpecialInterestGroup">SIGs</a> provide their community newer software on the slow-and-steady CentOS Linux.) This means EPEL is essential for work happening inside of the CentOS Project, but it remains a third-party repository. Figuring out all of the details of working together across the Fedora and CentOS projects is important for both communities.</p>
<p>Hope to see you there!</p>Karsten Wadehttp://iquaid.orgCentOS – i, quaid... the four laws of humanity ...http://iquaid.org/category/centos/feed/2016-11-10T15:11:32+00:00Kernel 3.10.0-327 issue on AMD Neo processortag:arrfab.net,2015-12-15:posts/2015/Dec/15/kernel-3100-327-issue-on-amd-neo-processor/2015-12-14T23:00:00+00:00<p>As CentOS 7 (1511) was released, I thought it would be a good idea to update several of my home machines (including kids' workstations) with that version, and also newer kernel.
Usually that's just a smooth operation, but sometimes some backported features/new features, especially in the kernel, can lead to some strange issues.
That's what happened for my older Thinkpad Edge : That's a cheap/small thinkpad that Lenovo did several years ago ( circa 2011 ), and that I used a lot just when travelling, as it only has a <a href="http://www.notebookcheck.net/AMD-Athlon-II-Neo-K325-Notebook-Processor.33886.0.html">AMD Athlon(tm) II Neo K345 Dual-Core Processor</a>.
So basically not a lot of horse power, but still something convenient just to read your mails, remotely connect through ssh, or browse the web.
When rebooting on the newer kernel, it panics directly.</p>
<p>Two bug reports are open for this, one on the <a href="https://bugs.centos.org/view.php?id=9860">CentOS Bug tracker</a>, linked also to the <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1285235">upstream one</a>. Current status is that there is no kernel update that will fix this, but there is a easy to implement workaround : </p>
<ul>
<li>boot with the initcall_blacklist=clocksource_done_booting kernel parameter added (or reboot on previous kernel)</li>
<li>once booted, add the same parameter at the end of the GRUB_CMDLINE_LINUX=" .." line , in the file /etc/default/grub</li>
<li>as root, run <code>grub2-mkconfig -o /etc/grub2.conf</code></li>
</ul>
<p>Hope it can help others too</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Kernel IO wait and megaraid controllertag:arrfab.net,2015-12-01:posts/2015/Dec/01/kernel-io-wait-and-megaraid-controller/2015-11-30T23:00:00+00:00<p>Last friday, while working on something else (working on "CentOS 7 userland" release for Armv7hl boards), I got notifications coming from our <a href="http://www.zabbix.org">Zabbix</a> monitoring instance complaining about <a href="https://www.zabbix.com/documentation/2.4/manual/web_monitoring">web scenarios</a> failing (errors due to time outs) , and also then also about "Disk I/O is overloaded" triggers (checking the cpu iowait time). Usually you'd verify what happens in the Virtual Machine itself, but even connecting to the VM was difficult and slow. But once connected, nothing strange, and no real activity , not even on the disk (Plenty of tools for this, but <a href="http://guichaz.free.fr/iotop/">iotop</a> is helpful to see which process is reading/writing to the disk in that case), but iowait was almost at 100%).</p>
<p>As said, it was happening suddenly for all Virtual Machines on the same hypervisor (CentOS 6 x86_64 KVM host), and even the hypervisor was suddenly complaining (but less in comparison with the VMs) about iowait too. So obviously, it wasn't really something not being optimized at the hypervisor/VMS, but something else. That rang a bell, as if you have a raid controller, and that battery for example is to be replaced, the controller can decide to stop all read/write cache, so slowing down all IOs going to the disk. </p>
<p>At first sight, there was no HDD issue, and array/logical volume was working fine (no failed HDD in that RAID10 volume), so it was time to dive deeper into analysis.</p>
<p>That server has the following raid adapter : </p>
<div class="highlight"><pre><span class="mi">03</span><span class="o">:</span><span class="mf">00.0</span> <span class="n">RAID</span> <span class="n">bus</span> <span class="n">controller</span><span class="o">:</span> <span class="n">LSI</span> <span class="n">Logic</span> <span class="o">/</span> <span class="n">Symbios</span> <span class="n">Logic</span> <span class="n">MegaRAID</span> <span class="n">SAS</span> <span class="mi">2108</span> <span class="o">[</span><span class="n">Liberator</span><span class="o">]</span> <span class="o">(</span><span class="n">rev</span> <span class="mi">03</span><span class="o">)</span>
</pre></div>
<p>That means that you need to use the <a href="http://www.avagotech.com/cs/Satellite?pagename=AVG2/searchLayout&SearchKeyWord=megacli&searchType=type-AVG_Document_C~Downloads&locale=avg_en&srchradio=null">MegaCLI</a> tool for that.</p>
<p>A quick <strong><code>MegaCli64 -ShowSummary -a0</code></strong> showed me that indeed the underlying disk were active but I got my attention caught by the fact that there was a "Patrol Read" operation in progress on a disk. I then discovered a useful (bookmarked, as it's a gold mine) <a href="http://fibrevillage.com/storage/175-lsi-megaraid-patrol-read-and-consistency-check">page</a> explaining the issue with default settings and the "Patrol Read" operation.
While it seems a good idea to scan the disks in the background to discover disk error in advance (PFA), the default setting is really not optimized : (from that website) : "will take up to 30% of IO resources"</p>
<p>I decided to stop the currently running patrol read process with <strong><code>MegaCli64 -AdpPR -Stop -aALL</code></strong> and I directly saw Virtual Machines (and hypervisor) iowait going back to normal mode.
Here is the Zabbix graph for one of the impacted VM, and it's easy to guess when I stopped the underlying "Patrol read" process : </p>
<p><img alt="VM iowait" src="https://arrfab.net/images/iowait.png" title="VM iowait" /></p>
<p>That "patrol read" operation is scheduled to run by default once a week (168h) so your real option is to either disable it completely (through <strong><code>MegaCli64 -AdpPR -Dsbl -aALL</code></strong>) or at least (adviced) change the IO impact (for example 5% : <strong><code>MegaCli64 -AdpSetProp PatrolReadRate 5 -aALL</code></strong>)</p>
<p><strong>Never</strong> understimate the power of Hardware settings (in the BIOS or in that case raid hardware controller). </p>
<p>Hope it can help others too</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00CentOS AltArch SIG statustag:arrfab.net,2015-09-24:posts/2015/Sep/24/centos-altarch-sig-status/2015-09-23T22:00:00+00:00<p>Recently I had (from an Infra side) to start deploying KVM guests for the <a href="https://en.wikipedia.org/wiki/Ppc64">ppc64</a> and <a href="https://en.wikipedia.org/wiki/Ppc64">ppc64le</a> arches, so that <a href="https://wiki.centos.org/SpecialInterestGroup/AltArch">AltArch</a> SIGs contributors could start bootstrapping CentOS 7 rebuild for those arches. I'll probably write a tech review about <a href="https://en.wikipedia.org/wiki/POWER8">Power8</a> and the fact you can just use libvirt/virt-install to quickly provision new VMs on <a href="http://www-03.ibm.com/systems/power/software/linux/powerkvm/">PowerKVM</a> , but I'll do that in a separate post.</p>
<p>Parallel to ppc64/ppc64le, <a href="https://en.wikipedia.org/wiki/ARM_architecture#32-bit_architecture">armv7hl</a> interested some Community members, and the discussion/activity about that arch is discussed on the <a href="https://lists.centos.org/mailman/listinfo/arm-dev">dedicated mailing list</a>. It's slowly coming and some users already reported having used that on some boards (but still unsigned and no updates packages -yet- )</p>
<p>Last (but not least) in this AltArch list is i686 : <a href="https://wiki.centos.org/JohnnyHughes">Johnny</a> built all packages and are already publicly available on <a href="http://buildlogs.centos.org/">buildlogs.centos.org</a> , each time in parallel to the x86_64 version. It seems that respinning the ISO for that arch and last tests would be the only things to do.</p>
<p>If you're interested in participating in AltArch (and have special interesting a specific arch/platform), feel free to discuss that on the <a href="https://lists.centos.org/mailman/listinfo/centos-devel">centos-devel</a> list !</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00CentOS Dojo in Barcelonatag:arrfab.net,2015-09-17:posts/2015/Sep/17/centos-dojo-in-barcelona/2015-09-16T22:00:00+00:00<p>So, thanks to the folks from Opennebula, we'll have another CentOS Dojo in Barcelona on Tuesday 20th October 2015. That even will be colocated with the <a href="http://2015.opennebulaconf.com/">Opennebulaconf</a> happening the days after that Dojo. If you're attending the OpennebulaConf, or if you're just in the area and would like to attend the CentOS Dojo, feel free to <a href="http://www.eventbrite.com/e/centos-dojo-barcelona-2015-tickets-18514955731">register</a></p>
<p>Regarding the Dojo content, I'll be myself giving a presentation about Selinux : covering a little bit of intro (still needed for some folks afraid of using it , don't know why but we'll change that ...) about selinux itself, how to run it on bare-metal, virtual machines <em>and</em> there will be some slides for the mandatory container hype thing.
But we'll also cover managing selinux booleans/contexts, etc through your config management solution. (We'll cover <a href="https://puppetlabs.com/">puppet</a> and <a href="http://www.ansible.com/">ansible</a> as those are the two I'm using on a daily basis) and also how to build and deploy custom selinux policies with your config management solution.</p>
<p>On the other hand, if you're a CentOS user and would like yourself to give a talk during that Dojo, feel free to submit a talk ! More informations about the Dojo on the <a href="https://wiki.centos.org/Events/Dojo/Barcelona2015">dedicated wiki page</a></p>
<p>See you there !</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Ext4 limitation with GDT blocks numbertag:arrfab.net,2015-09-10:posts/2015/Sep/10/ext4-limitation-with-gdt-blocks-number/2015-09-09T22:00:00+00:00<p>In the last days, I encountered a strange issue^Wlimitation with <a href="https://en.wikipedia.org/wiki/Ext4">Ext4</a> that I wouldn't have thought of. I've used ext2/ext3/ext4 for quite some time and so I've been used to resize the filesystem "online" (while "mounted"). In the past you had to use <a href="http://linux.die.net/man/8/ext2online">ext2online</a> for that, then it was integrated into <a href="http://linux.die.net/man/8/resize2fs">resize2fs</a> itself.</p>
<p>The logic is simple and always the same : extend your underlaying block device (or add another one), then modify the LVM Volume Group (if needed), then the Logical Volume and finally the resize2fs operation, so something like </p>
<div class="highlight"><pre>lvextend -L +<span class="cp">${</span><span class="n">added_size</span><span class="cp">}</span>G /dev/mapper/<span class="cp">${</span><span class="n">name_of_your_logical_volume</span><span class="cp">}</span>
resize2fs /dev/mapper/<span class="cp">${</span><span class="n">name_of_your_logical_volume</span><span class="cp">}</span>
</pre></div>
<p>I don't know how much times I've used that, but this time resize2fs wasn't happy :</p>
<div class="highlight"><pre><span class="n">resize2fs</span><span class="o">:</span> <span class="n">Operation</span> <span class="n">not</span> <span class="n">permitted</span> <span class="n">While</span> <span class="n">trying</span> <span class="n">to</span> <span class="n">add</span> <span class="n">group</span> <span class="err">#</span><span class="mi">16384</span>
</pre></div>
<p>I remember having had in the past an issue because of the journal size <a href="https://bugzilla.redhat.com/show_bug.cgi?id=160612#c27">not being big enough</a>. <code>But this wasn't the case here.</code></p>
<p>FWIW, you can always verify your journal size with <code>dumpe2fs /dev/mapper/${name_of_your_logical_volume} |grep "Journal Size"</code></p>
<p>Small note : if you need to increase the journal size, you have to do it "offline" as you have to remove the journal and then add it back with a bigger size (and that also takes time) :</p>
<div class="highlight"><pre>umount /<span class="nv">$path_where_that_fs_is_mounted</span>
tune2fs -O ^has_journal /dev/mapper/<span class="cp">${</span><span class="n">name_of_your_logical_volume</span><span class="cp">}</span>
# Assuming we want to increase to 128Mb
tune2fs -j -J size=128 /dev/mapper/<span class="cp">${</span><span class="n">name_of_your_logical_volume</span><span class="cp">}</span>
</pre></div>
<p>But in that case, as said, it wasn't really the root cause : while the <code>resize2fs: Operation not permitted</code> doesn't give much informations, <code>dmesg</code> was more explicit : </p>
<div class="highlight"><pre>EXT4-fs warning (device dm-2): ext4_group_add: No reserved GDT blocks, can't resize
</pre></div>
<p>The limitation is that when the initial Ext4 filesystem is created, the number of reserved/calculated GDT blocks for that filesystem will allow to grow it by a <a href="http://www.spinics.net/lists/linux-ext4/msg35015.html">factor of 1000</a>.</p>
<p>Ouch, that system (CentOS 6.7) I was working on had been provisioned in the past for a certain role, and that particular fs/mount point was set to 2G (installed like this through the <a href="https://en.wikipedia.org/wiki/Kickstart_(Linux)">Kickstart setup</a> ). But finally role changed and so the filesystem has been extended/resized some times, until I tried to extend it to more than 2TiB, which then caused resize2fs to complain ...</p>
<p>So two choices :</p>
<ul>
<li>you do it "offline" through <code>umount, e2fsck, resize2fs, e2fsck, mount</code> (but time consumming)</li>
<li>you still have plenty of space in the VG, and you just want to create another volume with correct size, format it, rsync content, umount old one and mount the new one.</li>
</ul>
<p>That means that I learned something new (one learns something new every day !), and also the fact that you then need to take that limitation in mind when using a kickstart (that doesn't include the <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html">--grow</a> option, but a fixed size for the filesystem).</p>
<p>Hope that it can help</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Implementing TLS for postfixtag:arrfab.net,2015-09-03:posts/2015/Sep/03/implementing-tls-for-postfix/2015-09-02T22:00:00+00:00<p>As some initiatives (like <a href="https://letsencrypt.org">Let's Encrypt</a> as one example) try to force <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security">TLS</a> usage everywhere. We thought about doing the same for the CentOS.org infra. Obviously we already had some <a href="https://en.wikipedia.org/wiki/X.509">x509</a> certificates, but not for every httpd server that was serving content for CentOS users. So we decided to <a href="https://lists.centos.org/pipermail/centos-announce/2015-August/021341.html">enforce</a> TLS usage on those servers. But TLS can be used obviously on other things than a web server.</p>
<p>That's why we considered implementing something for our <a href="http://www.postfix.org">Postfix</a> nodes. The interesting part is that it's really easy (depending of course at the security level one may want to reach/use). There are two parts in the postfix main.cf that can be configured :</p>
<ul>
<li>outgoing mails (aka your server sends mail to other SMTPD servers)</li>
<li>incoming mails (aka remote clients/servers send mail to your postfix/smtpd server)</li>
</ul>
<p>Let's start with the client/outgoing part : just adding those lines in your main.cf will automatically configure it to use TLS when possible, but otherwise fall back on clear if remote server doesn't support TLS :</p>
<div class="highlight"><pre># TLS - client part
smtp_tls_CAfile=/etc/pki/tls/certs/ca-bundle.crt
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
</pre></div>
<p>The interesting part is the <code>smtp_tls_security_level</code> option : as you see, we decided to force it to <code>may</code> . That's what Postfix <a href="http://www.postfix.org/TLS_README.html#client_tls_may">official TLS documentation</a> calls "Opportunistic TLS" : in some words it will try TLS (even with untrusted remote certs !) and will only default to clear if no remote TLS support is available. That's the option we decided to use as it doesn't break anything, and even if the remote server has a self-signed cert, it's still better to use TLS with self-signed than clear text, right ?</p>
<p>Once you have reloaded your postfix configuration, you'll directly see in your maillog that it will start trying TLS and deliver mails to servers configured for it : </p>
<div class="highlight"><pre>Sep 3 07:50:37 mailsrv postfix/smtp[1936]: setting up TLS connection to ASPMX.L.GOOGLE.com[173.194.207.27]:25
Sep 3 07:50:37 mailsrv postfix/smtp[1936]: Trusted TLS connection established to ASPMX.L.GOOGLE.com[173.194.207.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Sep 3 07:50:37 mailsrv postfix/smtp[1936]: DF584A00774: to=&lt;&gt;, orig_to=&lt;&gt;, relay=ASPMX.L.GOOGLE.com[173.194.207.27]:25, delay=1, delays=0/0.12/0.22/0.71, dsn=2.0.0, status=sent (250 2.0.0 OK 1441266639 79si29025652qku.67 - gsmtp)
</pre></div>
<p>Now let's have a look at the other part : when you want your server to present the STARTTLS feature when remote servers/clients try to send you mails (still in postfix main.cf) :</p>
<div class="highlight"><pre><span class="x"># TLS - server part</span>
<span class="x">smtpd_tls_CAfile=/etc/pki/tls/certs/ca-bundle.crt</span>
<span class="x">smtpd_tls_cert_file = /etc/pki/tls/certs/</span><span class="cp">&lt;%=</span> <span class="n">postfix_myhostname</span> <span class="cp">%&gt;</span><span class="x">-postfix.crt </span>
<span class="x">smtpd_tls_key_file = /etc/pki/tls/private/</span><span class="cp">&lt;%=</span> <span class="n">postfix_myhostname</span> <span class="cp">%&gt;</span><span class="x">.key</span>
<span class="x">smtpd_tls_security_level = may</span>
<span class="x">smtpd_tls_loglevel = 1</span>
<span class="x">smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache</span>
</pre></div>
<p>Still easy, but here we also add our key/cert to the config but if you decide to use a signed by a trusted CA cert (like we do for centos.org infra), be sure that the cert is the concatenated/bundled version of both your cert and the CAChain cert. That's also documented in the <a href="http://www.postfix.org/TLS_README.html#server_cert_key">Postfix TLS guide</a>, and if you're already using <a href="http://www.nginx.org">Nginx</a>, you already know what I'm talking about as you <a href="http://nginx.org/en/docs/http/configuring_https_servers.html#chains">already have to do it</a> too.</p>
<p>If you've correctly configured your cert/keys and reloaded your postfix config, now remote SMTPD servers will also (if configured to do so) deliver mails to your server through TLS. Bonus point if you're using a cert signed by a trusted CA, as from a client side you'll see this : </p>
<div class="highlight"><pre>Sep 2 16:17:22 hoth postfix/smtp[15329]: setting up TLS connection to mail.centos.org[72.26.200.203]:25
Sep 2 16:17:22 hoth postfix/smtp[15329]: Trusted TLS connection established to mail.centos.org[72.26.200.203]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Sep 2 16:17:23 hoth postfix/smtp[15329]: CC8351C00C9: to=&lt;fake_one_for_blog_post@centos.org&gt;, relay=mail.centos.org[72.26.200.203]:25, delay=1.6, delays=0.19/0.03/1.1/0.31, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A7299A006E2)
</pre></div>
<p>The <code>Trusted TLS connection established</code> part shows that your smtpd server presents a correct cert (bundle) and that the remote server sending you mails trusts the CA used to sign that cert.</p>
<p>There are a lot of TLS options that you can also add for tuning/security reasons, and all can be seen through <code>postconf |grep tls</code>, but also on the Postfix <a href="http://www.postfix.org/postconf.5.html#smtp_tls_ciphers">postconf doc</a></p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Update on CentOS GSoC 2015http://iquaid.org/?p=24202015-06-02T15:34:33+00:00<p>Here&#8217;s an update on the CentOS Project Google Summer of Code for 2015 posted on the <a href="http://seven.centos.org">CentOS Seven blog</a>:</p>
<p><a href="http://seven.centos.org/2015/06/centos-and-gsoc-2015-suddenly-come-seven-on-7/">http://seven.centos.org/2015/06/centos-and-gsoc-2015-suddenly-come-seven-on-7/</a></p>
<p>This might be of interest to the Fedora Project community, so I&#8217;m pushing my own reference here to appear on the Fedora Planet. Much of the work happening in the CentOS GSoC effort may be useful as-is or as elements within Fedora work. (In at least one case, the <a href="https://www.google-melange.com/gsoc/project/details/google/gsoc2015/mndar/5717271485874176">RootFS build factory for Arm</a>, the work is also happening partially in Fedora, so it&#8217;s a triple-win.)</p>Karsten Wadehttp://iquaid.orgCentOS – i, quaid... the four laws of humanity ...http://iquaid.org/category/centos/feed/2016-11-10T15:11:32+00:00CentOS 7 armv7hl build in progresstag:arrfab.net,2015-05-21:posts/2015/May/21/centos-7-armv7hl-build-in-progress/2015-05-20T22:00:00+00:00<p>As more and more people were showing interest in CentOS on the ARM platform, we thought that it would be a good idea to start trying building CentOS 7 for that platform. Jim started with arm64/aarch64 and got an <a href="http://lists.centos.org/pipermail/centos-announce/2015-May/021102.html">alpha build ready</a> and installable.</p>
<p>On my end, I configured some armv7hl nodes, "donated" to the project by <a href="https://www.scaleway.com">Scaleway</a>. The first goal was to init some <a href="http://www.fedoraproject.org/wiki/Projects/Plague">Plague builders</a> to distribute the jobs on those nodes, which is now done. Then working on a "self-contained" buildroot , so that all other packages can be rebuilt only against that buildroot. So building first gcc from CentOS 7 (latest release, better arm support), then glibc, etc, etc ... That buildroot is now done and is available <a href="http://armv7.dev.centos.org/repodir/c7-buildroot/">here</a>.</p>
<p>Now the fun started (meaning that 4 armv7hl nodes are currently (re)building a <em>bunch</em> of SRPMS) and you can follow the status on the <a href="http://lists.centos.org/mailman/listinfo/arm-dev">Arm-dev List</a> if you're interested, or even better, if you're willing to join the party and have a look at the build logs for packages that failed to rebuild. The first target would be to have a "minimal" install working, so basically having sshd/yum working. Then try other things like GUI environment.</p>
<p>As plague-server required mod_python (deprecated now) we don't have any Web UI people can have a look at. But I created a "quick-and-dirty" script that gathers information from the mysql DB, and outputs that here :</p>
<ul>
<li><a href="http://armv7.dev.centos.org/queue.html">Packages in the current queue</a></li>
<li><a href="http://armv7.dev.centos.org/report.html">Packages in a "failed" status</a> (with link to the log files)</li>
</ul>
<p>The other interesting step will be to produce .img files that would work on some armv7hl nodes. So diving into <a href="http://www.denx.de/wiki/U-Boot">uboot</a> for <a href="http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433">Odroid C1</a> (just as an example) ....</p>
<p>I'll also try to maintain a <a href="http://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32">dedicated Wiki</a> page for the arm32 status in the following days/weeks/etc ..</p>Fabian Arrotinhttps://arrfab.net/Arrfab's Bloghttps://arrfab.net/2016-11-25T17:30:03+00:00Firefox 38 and TLS less than 1.2tag:blogger.com,1999:blog-7607366660500015746.post-43241282185116354532015-05-13T05:19:48+00:00<pre>Red Hat released the source code for Firefox 38. We have (or willbe<br />today) releasing this for CentOS-5, CentOS-6, and CentOS-7.<br /><br />It does not, by default, connect to https sites with TLS less than 1.2. <br />This means it will not connect to sites on CentOS-5, for example ..<br />there are many others.<br /><br />In any event, here is a wiki article that explains potential issues and<br />workarounds:<br /><br /><a class="moz-txt-link-freetext" href="http://wiki.centos.org/TipsAndTricks/Firefox38onCentOS">http://wiki.centos.org/TipsAndTricks/Firefox38onCentOS</a></pre>Johnny Hughesnoreply@blogger.comhttp://centosnow.blogspot.com/CentOS Nowtag:blogger.com,1999:blog-76073666605000157462016-12-10T02:30:04+00:00