top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

File system re-sizing with cloud-init on centos or redhat.

+1 vote
68 views

Has any one used resizefs module with cloud-init on centos/redhat before? How to call it with #cloud-config user data, do I need to give it any parameters? I googled cloud-init, but it is pretty difficult to find a manual/book on this, and mostly they are Ubuntu based.

If possible, I'd like to use a same image/AMI to boot up instances(VMs) with different disk size setup, and let cloud-init to take care of increasing partition size, and file system re-sizing. Is it possible for centos/redhat?

posted Aug 6, 2013 by Naveena Garg

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button
Take a look at growroot included in cloud-init

Similar Questions
0 votes

Wonder how's the relationship between the centos 6's main OS/ repository and redhat 6's repositories. Let's say, Redhat 6 seperate RPMs into a series of repos like:

redhat-6-server ##(base redhat 6 OS/)
redhat-6-server-optional
redhat-6-server-supplementary
redhat-6-server-rhev-agent
rhel-6-server-cf-tools
...

Does centos 6 merge all the redhat 6 repos into one big repository? or still leave out some minor/functional ones? If the second is true, then it will be great if we can find the repo mapping link between Redhat 6 and centos 6.

0 votes

I am setting up Apache on Redhat and have the following errors:

Starting httpd: httpd: Syntax error on line 59 of /etc/httpd/conf/httpd.conf: Cannot load
/etc/httpd/modules/mod_perl.so into server: /etc/httpd/modules/mod_perl.so: cannot open shared object file: No such file or directory
[FAILED]

I have the following 3 lines in the httpd.conf file

ServerRoot "/etc/httpd" - This was already their
LoadModule perl_module modules/mod_perl.so
PerlSwitches -w -T
PerlConfigRequire /var/www/html/bugzilla/mod_perl.pl

I am not sure what else I need to do fix this error.

0 votes

I recently migrated approximately 100 rhel 6 machines from NFS3 to NFS4 (server is rhel 6.6, clients are a mix from 6.3 to 6.6). Things went pretty smooth until several hours into the new configuration, then things started
running very slowly. Restarting the nfs server process clears the issue which seems to indicate the server is the problem.

The file system itself can do some very high io throughput, on the order of 1GB/sec sustained and the "th" values in /proc/net/rpc/nfsd never increase which indicates i/o's are completing on time with no thread starvation. The server itself is set for 384 threads. During the previous NFS3 config the thread count was much higher and had no problems.

I suspect file locking as the primary application in use ( an in house app) uses a lot of little startup scripts which call other scripts to set up the environment etc. Under normal circumstances this startup takes about 6 seconds. Over time that duration increases up to 30 and even 70 seconds in some cases.

I've scoured every reference to nfs4 performance degradation I could find but nothing seems to call out what we are experiencing. A few retrans exist in nfsstat but nothing that stands out. Generally, everything "look" OK but
clearly is not.

Oh, and this is all being run over 10G Ethernet. If memory serves, I believe the kernel is 2.6.2-504.8.1 on the server.

Any ideas about what else to check would be greatly appreciated.

0 votes

Following 2 vulnerabilities were detected in VA scan required for PCI compliance:

  1. SSL Weak Cipher Suites Supported
  2. SSL Medium Strength Cipher Suites Supported

I'm using CentOS 5.8 with open ssl version "openssl-0.9.8e-22.el5_8.4". Any idea how to get rid of this?

+1 vote

I was just wondering, is there a "correct" or "preferred" way of setting up the path and other environment variables for Qt 4 development/build using qmake and all - on a CentOS 6 system?

I mean, this does not work out-of-the box, at least if you have build files that assume "qmake" may be executed just like that - as there is no Qt 4 qmake on the path, although "qmake-qt4" is available. Also, if
qt3-devel is installed, and the default path setup is used, "qmake" will point to the Qt 3 version, as the package includes a profile.d file that modify the path in such a way. Which also sets up other Qt related
variables, I believe. There is no such file in qt4-devel, however.

I know ways to set up everything so that this works as expected, of course, but it would be interesting to know how the packagers intended it to be done. Are you expected to edit login files by hand? That's sort
of surprising in this day and age... Or is the thinking that the suffixed ("-qt4") version of commands will always be used? Or that everyone will be using plain make with pkg-config? Or is there some other mechanism that should to be used to select the right Qt version?


Useful Links with Similar Problem
Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.
QUERY HOME
...