Managing Fedora 20 within an OpenVZ environment

fouadChk

Member
First off, thanks to the Giga Team for providing me with the opportunity to check on their free VPS offerings. Although, system security and administration is nothing new to me, having to exerce that Art on a live system within a virtual environment is indeed a brand new experience to me to say the least.

Now, i've spent sometime trying to configure this VPS of mine and for the time being I've still didn't add any service to it besides those already running out-of-the-box. The reason for this is that I did stumble with a rather unexpected issue concerning the system's time which is grossly inaccurate: ~5 hours in advance
vzctl set VMID --capability sys_time:eek:n --setmode restart --save
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Besides the problem of the out of sync system time inside the VPS, I also run into the problem of finding that Virtualizor isn't installed at all although I was given its login. Not sure how that occured. Is it a step that was skipped during the VPS creation or has it failed when it was run. From my logs, I couldn't detect any trace of it.

This issue however isn't critical as far as I'm concerned. I was planning to disactivate its service anyway. I'm more at ease with the manual administration of a system than with all those script-based GUIs.

Running the following systemd cmd to get the list of the services that fails at system satrtup:
PHP:
#systemctl --state=failed
UNIT?????????????????????????? LOAD?? ACTIVE SUB??? DESCRIPTION
systemd-sysctl.service???????? loaded failed failed Apply Kernel Variables
systemd-vconsole-setup.service loaded failed failed Setup Virtual Console
vzquota.service??????????????? loaded failed failed LSB: Start vzquota at the end of boot

LOAD?? = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB??? = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

I suspect that the first 2 failures are due to the OpenVZ environment... and hopefully without any impact on sytem stability. The last one I still didn't document it at this point.

Those are my two main feedback/heads-up that I have for the moment. And thanks for any assistance concerning the out-of-sync time issue.
 

fouadChk

Member
No problem Genesis. At the end of the day, the VPS is largely for Web experimentation and a learning opportunity on how to properly manage a Live VPS with all its services on.

Thanks!
 

fouadChk

Member
fouadChk said:
Besides the problem of the out of sync system time inside the VPS, I also run into the problem of finding that Virtualizor isn't installed at all although I was given its login. Not sure how that occured. Is it a step that was skipped during the VPS creation or has it failed when it was run. From my logs, I couldn't detect any trace of it.

This issue however isn't critical as far as I'm concerned. I was planning to disactivate its service anyway. I'm more at ease with the manual administration of a system than with all those script-based GUIs.

Well, it turns out that I did misunderstood the whole Virtualizor setup. Virtualizor is install inside the main node (which is the VMs host) and give VM admins a hollistic vue of their system via its GUI and allows them to control over some of their system's key config settings and features (just like cPanel does for webmasters concerning Apache/PHP/MySQL stack settings.)

The reason why I said in my previous OP that I would rather have virtualizor disabled is 2 fold and just reflects the fact that I've never used it before:
> I thought it was installed inside the VM (I was given the VM IP for its login which suggested that.) Given that we have just 512MB as RAM, having this kind of soft inside is just out of the question for me.

> The second thing is that I'm new to OpenVZ VMs and, given the hours I've spent with them lately, I'm now aware of the many limitations that an OpenVZ VM has (by design) which makes the additional controls that virtualizor supplies vital.

######################
Note: This post addresses my virtualizor misconception that a (newbie) reader will be faced with in my OP and hoppefully will help future newbies.
 

fouadChk

Member
This should be my last post in this thread about what turns out to be a brief 'flirt' with Fedora 20 on GigaRank VPS hosting. A couple of days ago I just dropped it out of frustration. Here is the whole rational for this for anyone interested.

When choosing Fedora-20, I had in mind the possibility of upgrading it to the latest version then start building something around it. That (in a sense) was equivalent to have a Centos 7 (RHEL-7 and Centos-7 are built on the new features adopted in Fedora 20 onward.) On the other hand Fedora 20 and 21 (and sooner 22) are all EOL.

I did try to upgrade it not once by twice and guess what happened. The upgrade went flawlessly but once I perform the OS restart, I was locked out of my SSH login. I did some thinking on the issue and it seems to me that the problem lays in the SysV that the upgrade removes (obsolete on Fedora 21.) And without the sysinit, xinetd daemon isn't started and the 3 key services on which OpenVZ virt. rely to start its system guests fail.

I didn't want to waste more time on this (out of frustration) and simply reinstalled (the old way of doing things)/Centos 6, which at least is in its latest version and will be supported till 2020.

So long Fedora!
 

fouadChk

Member

In my case, it's the OpenVZ VE that didn't help. I will open a separate thread in the general discussion on VPS forum to record few thoughts on it (the OpenVZ virtualization I mean) as well as on the way I handled my VPS---no control panel involved, just plain old command line and custom shell scripts. A bit old-fashioned for todays' point-&-click type of users.