Login with the servers root details. After you login, you will see the Admin Panel Dashboard: Ports. Virtualizor uses ports from 4081 – 4085. We at IIT Kharagpur are having problems with building the OVPL container. CentOS 6.5 is not available on the net. We are using CentOS 7.0. Kernel information is shown below. # uname -a Linux localhost.localdomain 3.10.0-123.20.1.el7.x86.
Senior MemberFrom:.sw.ru02:00.0 RAID bus controller: 3ware Inc Unknown device 1005 (rev 01)02:00.0 0104: 13c1:1005 (rev 01)Ok, it looks like 3w-9xxx.ko module should handle this device fine.Quote:Don't understand what you mean. Junior MemberFrom: 89.128.81.Hi again, not my kvm.
Also I have not phisical access to the server, unless I drive 400 Km. Junior MemberFrom: 89.128.81.Yes I could you give access via PM, one thing more before, I tried for the last time to clean up the mess I made and remove the ovzkernel and install again via yum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Today!Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.Are you new to LinuxQuestions.org?
![Openvz Requires: /sbin/mkinitrd Openvz Requires: /sbin/mkinitrd](/uploads/1/2/5/6/125620878/956674890.png)
Visit the following links: If you have any problems with the registration process or your account login, please. If you need to reset your password,.Having a problem logging in? Please visit to clear all LQ-related cookies. Introduction to Linux - A Hands on GuideThis guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.to receive this Complete Guide absolutely free.
Is there any good reason that we shouldn't just add the /sbin paths to the regular user $PATH and end this nonsense once and for all? It's not like we get any extra security from having different root and regular user paths - users could always try to execute things anyway by providing the path to the binary. It would sure stop a lot of common problems with using su/sudo.volkerdi -None that I know of ( I wondered more-or-less the same thing in another rairly-recent thread )And /etc/profile could be simplified a tad too!You've got my vote ( if that matters )- kjh. Quote:## Uncomment to use a hard-coded PATH instead of the user's to find commands# Defaults securepath='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'It should be noted that using sudo is not a normal thing for many Slackers. The concept of using sudo to run all administrative commands is something introduced by Ubuntu to simplify administration, but it also makes security a bit worse.
Sudo was originally designed to allow system administrators to give certain users the ability to run a limited set of commands with elevated permissions.In regards to your guide, I'm not sure that having a user add themselves to the /etc/sudoers file is the best thing in a Slackware guide. It might be better to introduce them to su - rather than editting the sudoers file. Especially since that will work on any system out of the box and doesn't require manually editing a file to make it happen. Is there any good reason that we shouldn't just add the /sbin paths to the regular user $PATH and end this nonsense once and for all?
It's not like we get any extra security from having different root and regular user paths - users could always try to execute things anyway by providing the path to the binary. It would sure stop a lot of common problems with using su/sudo.I've been adding my main user to the /sbin/ paths for many, many years. It gives a regular user access to utilities that they are allowed to run, but are hidden in /sbin/ or /usr/sbin/, like lspci. You can get some good info from lspci as a regular user.
I'm sure there's plenty of other examples, but I'm too lazy to look into them. As you said, the security isn't a great reason since users can just run it with the full path. Users will either get an error message or limited access to the program, but I don't really see any downsides (except for confusion by some when they run removepkg as a user and it just spits out errors).It'd be awesome to add the sbin paths to all users on the next version of Slackware. It should be noted that using sudo is not a normal thing for many Slackers. The concept of using sudo to run all administrative commands is something introduced by Ubuntu to simplify administration, but it also makes security a bit worse.
Sudo was originally designed to allow system administrators to give certain users the ability to run a limited set of commands with elevated permissions.In our organization, we primarily use sudo to avoid giving out the root password. We can easily reduce or revoke an individual's sudo privileges, but changing the root password is quite a bit harder since it entails letting all remaining privileged users know the new password, as well as changing it on every computer in the network.Thus I elected to use sudo because it is familiar to us. Furthermore, I used sudo only for commands that require it, so it indicates which commands need write access beyond the confines of $HOME. In regards to your guide, I'm not sure that having a user add themselves to the /etc/sudoers file is the best thing in a Slackware guide. It might be better to introduce them to su - rather than editting the sudoers file. Especially since that will work on any system out of the box and doesn't require manually editing a file to make it happen.This particular Slackware guide isn't for teaching system administration or even producing a Slackware system for daily use. My guide exists to document the process by which I created a virtual machine appliance whose purpose is cross compilation targeting various platforms.
Odds are good that no one will ever actually read the guide now that I have it written and the filesystem image produced, but nevertheless configuration management requires that I capture my processes rather than rely on a one-off blob whose assembly is undocumented and no one can reproduce.That doesn't mean I'm okay cutting corners. It is my hope that someday we can branch out and use my guide as the basis for more Slackware systems, especially now that we're on the verge of getting sucked into Red Hat Enterprise Linux 7 and systemd.Please don't let this thread devolve into Yet Another Systemd Discussion. I only mention it in passing because it is the highest profile reason why I leapt at the opportunity to use Slackware for this task rather than RHEL. In our organization, we primarily use sudo to avoid giving out the root password. We can easily reduce or revoke an individual's sudo privileges, but changing the root password is quite a bit harder since it entails letting all remaining privileged users know the new password, as well as changing it on every computer in the network.Thus I elected to use sudo because it is familiar to us.
Furthermore, I used sudo only for commands that require it, so it indicates which commands need write access beyond the confines of $HOME.This particular Slackware guide isn't for teaching system administration or even producing a Slackware system for daily use. My guide exists to document the process by which I created a virtual machine appliance whose purpose is cross compilation targeting various platforms. Odds are good that no one will ever actually read the guide now that I have it written and the filesystem image produced, but nevertheless configuration management requires that I capture my processes rather than rely on a one-off blob whose assembly is undocumented and no one can reproduce.This makes plenty of sense and I'm glad to see you're using sudo as it was originally intended.
![Openvz Requires: /sbin/mkinitrd Openvz Requires: /sbin/mkinitrd](/uploads/1/2/5/6/125620878/976274718.png)
Many times when we see people making guides with sudo, it's making sudo available for all programs for a user to mimic Ubuntu. It's not necessarily wrong to do that (I do it with my main user), but it isn't the standard Slackware set up and people should know what they're doing (that last bit wasn't directed at you, but just clarifying things in case anyone else was wondering what I was intending).But short of modifying mkinitrd itself, you could make the changes in /etc/sudoers that I mentioned above to set a particular PATH to be used when using sudo. This will solve the issue for everyone that uses that system. There exists an argument for leaving /sbin out of not only user $PATH but also root $PATH. That is: make root (or user having sudo) work a little bit harder to run potentially dangerous commands. The theory is that if you're forced to type '/sbin' you are acknowledging that you really do mean to run special system administration commands.
I don't buy this argument. There's plenty of dangerous stuff in /bin, e.g. It's not the commands that are privileged or dangerous but rather the operations they perform.
For example, bash will happily zap a file without even forking ('/boot/vmlinuz').I agree that in the case of shell environments, security is primarily through the user privileges and secondarily (or not at all) through the commands executed.When I open a shell as root it's as though I'm in possession of a sharp knife/tool with few or no safety features. Knowledge/training is what keeps me from cutting myself or others. I didn't accidentally stumble into root privileges, I had to use the root password. Now get out of my way and let me use the sharp knife/tool to work. (I do see a role for sudo functions however.)Although built-in safeguards can be helpful (or a pain in the ass), I don't believe that we should rely on them.
I try to do the proper action as though the safeguard was not in place.Rather than than rely on a particular shell environment to do the right thing I've learned to follow personal best practices when typing commands and running impromptu scripts.A simple example of this is that I never type the command ' su', I always type ' /bin/su'. I'm about to tell a computer program the root password. I want to be careful what program I'm giving the password to. I don't want it to be a Trojan horse. Is there any good reason that we shouldn't just add the /sbin paths to the regular user $PATH and end this nonsense once and for all?I've seen where less knowledgeable (clueless) users find more bugs in software than the experts. The experts know what NOT to try while the new users don't know better and try combinations that a knowledgeable user or tester didn't.In adding /sbin & /usr/sbin to a regular user's path we may see some interesting effects when daemons and utilities are executed as a regular user in unusual ways.
Most likely not however, as the programs have probably been thoroughly abused.