hi all, I am getting error in installing Host in ovirt-engine.Can anyone tell me how to eliminate the error. I'm attaching the screenshot of error.
Thanks
Hi all,
As a newcomer on the list with not much time, but enough to hopefully be
a bit useful to the upcoming CentOS7 release, i'm wondering what the
best action is I could take? I'm seeing lots of things happening here
and in other places like CentOS but not sure if is there is something i
could focus on or help out?
I'm seeing some info at http://seven.centos.org/ about t_functional, but
i'm not sure if that is the place where help would be welcome, and if
so, how to proceed to be honest.
gr,
josh
hi,
soliciting comments on http://bugs.centos.org/view.php?id=6820 ( which
deals with the partial component inclusion of glusterfs into the base
distro ). There are a couple of workarounds mentioned there, but none
seem perfect.
In an ideal world, it would be nice if Red Hat had their RHS gluster
rpms in line with the gluster rpms shipped in the base distro and we
could use those into CentOS-Extras.
the closest other practical option seems to be building gluster --with
server enabled, and shipping the extra rpms into CentOS-Extras; provided
the '--with server' is retained going forward, this would atleast mean
we have version sync between the client code in the distro and the
server code in CentOS Extras.
The option of just adding all the gluster code into the distro we ship,
server and client content included, seems very intrusive and might have
an impact on third party expectations.
- KB
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
Hi,
As posted in this bug http://bugs.centos.org/view.php?id=6843 there are
now problems with the current firefox on CentOS 5 to shutdown firefox
cleanly.
If others experience the same please report if you can reproduce it.
While we are at it, may it be possible for the developers to rebuild the
package with the correct config as shown here:
http://bugs.centos.org/view.php?id=6843#bugnotes
If it makes no difference then we at least know that it may also happen
with upstreams package.
Regards and thanks for all the hard work!
Simon
Hi,everyone
http://www.redhat.com/archives/shrike-list/2003-April/msg00069.htmlhttp://fedoraproject.org/wiki/StackTraceshttp://old-en.opensuse.org/Packaging/Debuginfo
This document said:"passing -g to gcc or g++". And "Note that the default CFLAGS and CXXFLAGS of the distro already contain -g, "
My question is :
I build souce code a.c with myself gcc/make configfile.
first time: compile a.c with -O2,then get a1.bin
second time: compile a.c woth -O2 -g,then strip debug symbols.then get a2.bin
But i find a2.bin is slower then a1.bin.The performance of a2.bin is 5% slower.
Should a2.bin run as fast as a1.bin?(performance is same?)//Tomorrow i will provide the complete commands.
Can anyone give some advice?
I find that:rpmbuild run gcc one time with -g -O2,then get a.rpm and a.debuginforpm.
thanks.
I am out of the office until 12/02/2013.
Please contact hss(a)biotronik.com in urgent cases.
Note: This is an automated response to your message "Re: [CentOS-devel]
CentOS-6.4 OpenStack testing cloud images" sent on 25.11.2013 13:24:03.
This is the only notification you will receive while this person is away.
www.biotronik.com
BIOTRONIK - Celebrating 50 years of excellence
Founded in 1963 with the development of the first German pacemaker, BIOTRONIK has brought innovations and the highest quality standards to the cardiac rhythm management and vascular intervention fields in more than 100 countries around the world. We’ve developed advanced technologies such as BIOTRONIK Home Monitoring®, Closed Loop Stimulation (CLS) and Orsiro, the industry's first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio of cardiac devices with ProMRI®, an advanced technology that gives patients access to magnetic resonance (MR) scanning.
BIOTRONIK SE & Co. KG
Woermannkehre 1, 12359 Berlin, Germany
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
Vertreten durch ihre Komplementärin:
BIOTRONIK MT SE
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B
Geschäftsführende Direktoren: Christoph Böhmer, Dr. Lothar Krings
This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document.
Hi KB,
Sorry for the delayed response, I wasn't subscribed to the devel list.
I'm also replying to some of the comments that other users posted.
Sorry for messing up the thread.
I tested your image in OpenStack Havana with KVM so my comments are
very much OpenStack centric.
> Hi,
> CentOS-6.4 i386 and x86_64 images targetting OpenStack are now available
> for testing at http://dev.centos.org/centos/hvm/ Images are available
> for KVM, Hyper-V, VMware, Xen and any other HVM hypervisor. Although,
> the 6.x kernel has the pv support enabled, so should work fine under
> paravirt Xen as well.
> Images are published as raw, qcow2 qcow2compressed and vpc ( vhd ) for
> both i386 and x86_64 CentOS-6.4 The images represent media versions, and
> have not had an update run against them. Its highly recommended that in
> testing, please check this version *then* do a yum update and repeat
> tests to ensure that there is no test result change in the 6.4+updates
> tree's.
> Keeping in line with the general CentOS Cloud strategy, ie to help
> people migrate or investigate cloud instances, we expect the images to
> represent as close as possible to a real machine CentOS install ( ie. no
> cloud specific user, people use root to login, selinux is enabled ).
I'd prefer a non-root default user to be inline with the other
community images. IMHO it's a convenience to not have to create a
non-root user after spinning up an instance. But cloud-init will take
care of all that for you, if you configure it correctly, which doesn't
seem to be the case in your image. I.e., cloud-init creates a
'cloud-user' and disables root login but for some reason the
cloud-user is not allowed to sudo (should be handled by cloud-init) so
there's no way to gain root permissions.
In general, the cloud environment has no business in mocking with a
guest image. Yes, OpenStack is still injecting keys but that is likely
to change (I believe). It should be up to the instance to configure
itself which is what we have cloud-init for. In terms of users, I vote
for:
- A 'centos' default user without a password (no console login) and
password-less sudo permissions. This follows Fedora and Ubuntu and to
some degree Debian conventions. IIRC Debinan uses 'admin' as the
default user.
- Disabled root login and certainly no standard well-known password
which is simply a security disaster waiting to happen.
I'm not too crazy about SSH password access and cloud-init disables
that as well (unless you tell it not to).
In general, a cloud image should be as locked-down as possible to
reduce the risk of somebody else taking over your instance before you
can get to it. Providing SSH key access is the preferred method.
Everything else can be enabled later or when the instance is launched
(for example by providing a configuration script that cloud-init
executes on first boot). Similarly, selinux should be enabled by
default. The firewall can be discussed. I think it's not required
since the cloud environment already provides that functionality and
you have to specifically open ports to get access to your instance.
As for console logins, why would we want that in the base image? Can
somebody give a use case? I just don't see it as useful. We have SSH
access and as mentioned everything else required/desired should be
enabled/configured once the instance is up. If SSH access doesn't work
after first boot, then there's something fundamentaly broken and
console access will most likely not work either.
LVM: What's the rational for using LVM? It's not like we can just add
another disk to the instance and add it to the volume. IMHO it just
adds unnecessary overhead and breaks the growroot functionality.
dracut-modules-growroot (which I maintain in EPEL) doesn't support
LVM.
swap: Providing a swap device in a cloud image is debatable as well.
Some clouds charge for IOs and you don't want to pay for swap activity
so the cloud images I'm aware of don't have a predefined swap device.
Again, it can always be added later if need be.
console: As mentioned by others, please add 'console=tty1' to the
kernel commandline to get some messages on the virtual console:
'console=tty1 console=ttyS0' (See
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695 for
the rational to use tty1 instead of tty0).
If you try to make this image as close to regular CentOS as possible,
you might confuse other cloud users that are used to certain things in
other cloud images. Although those 'things' are not standardized and
we're not required to follow them. It's a balancing act, I guess.
> CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2
> CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2
Why the bzip2 compression on top of qcow compression? It doesn't
create much smaller files and requires and extra step after
downloading the images. No big deal, though.
> Enjoy!
Good work!
...Juerg