Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › 10 mistakes new Linux administrators make
New Posts  All Forums:Forum Nav:

10 mistakes new Linux administrators make - Page 5

post #41 of 51
Quote:
Originally Posted by Rookie1337 View Post

See above. I was failing to explain that for the general user on a non-server environment it wouldn't make much sense(or maybe it would so it's up to choice). But you have me curious about the administration field. Namely I'm curious just what people use the most of; Debain, RHEL, Gentoo, Slackware, or do they make customized setups from scratch?

Depending on the budget, companies will probably choose the item with support. It's the reason red hat is successful. They want to be able to send their big issues to someone else they've paid money to. At my work we have a few non RHEL servers, mostly because the application called for it. And with VMware, we can install as many puny machines as we like.
post #42 of 51
Quote:
Originally Posted by ramkatral View Post

Where does the logic of "a little bit of performance increase doesn't matter" come from? We are on a site of users dedicated to milking every last ounce of performance out of systems. As a professional administrator, your JOB is to get every centimeter of performance out of the server possible. Little things add up.
Maybe that's a divider of a novice and a professional. A professional will take the extra time and "trouble" to make it just "a little bit" better and faster.

In the professional world, it's about stability, not performance necissarily. Users would rather have a system that is running smoothly, and be a little slower than a system that's very fast, but constantly breaks and requires maintenance.
post #43 of 51
Quote:
Originally Posted by herkalurk View Post

In the professional world, it's about stability, not performance necissarily. Users would rather have a system that is running smoothly, and be a little slower than a system that's very fast, but constantly breaks and requires maintenance.

^^ This. Amen! Dragsters are exciting but none of us drive one to work.
NewMain
(16 items)
 
  
CPUMotherboardGraphicsRAM
Intel i5 - 3550 Asrock Z77 Extreme4 Gigabyte GTX 760  4x2GB Corsair Vengeance 
Hard DriveOptical DriveCoolingOS
Seagate SATA 2TB x 2  Plextor PX-891SAW CM-Hyper N520 Slackware 14, Studio KUbuntu, OpenSuSe 12.3, Wi... 
MonitorKeyboardPowerCase
32" Vizio HDTV + DLP Logitech Wireless Corsair HX-850 Antec Sonata I 
MouseMouse PadAudioOther
Razer DeathAdder 2013 dual ESI Juli@ CoolGear ExtSata Enclosure w/ Optical and 3TB S... 
  hide details  
Reply
NewMain
(16 items)
 
  
CPUMotherboardGraphicsRAM
Intel i5 - 3550 Asrock Z77 Extreme4 Gigabyte GTX 760  4x2GB Corsair Vengeance 
Hard DriveOptical DriveCoolingOS
Seagate SATA 2TB x 2  Plextor PX-891SAW CM-Hyper N520 Slackware 14, Studio KUbuntu, OpenSuSe 12.3, Wi... 
MonitorKeyboardPowerCase
32" Vizio HDTV + DLP Logitech Wireless Corsair HX-850 Antec Sonata I 
MouseMouse PadAudioOther
Razer DeathAdder 2013 dual ESI Juli@ CoolGear ExtSata Enclosure w/ Optical and 3TB S... 
  hide details  
Reply
post #44 of 51
Quote:
Originally Posted by enorbet2 View Post

^^ This. Amen! Dragsters are exciting but none of us drive one to work.

You might not, but given the chance.... I so would. thumb.gif
post #45 of 51
Quote:
Originally Posted by Shrak View Post

#1 can be easily avoided, compile the source and install by user from your package manager (most provide this technique for those that can only be had from source).

That still doesn't cover if a lib gets merged and then the lib functions get screwed (cover later).
Quote:
Originally Posted by ramkatral View Post

Pacman is one of those decent managers. It installs from source. I dislike the managers that have some unique format. I'm not totally against managers, just the kind that take off and start installing crap other than specifically what you tell it to. I prefer to resolve my own dependencies.
In the end, I always just compile my own source. It seems to be becoming a lost art.

Pacman doesn't do anything special, your pulled in by the AUR or ABS, pacman does nothing something like apt-get doesn't already do: apt-get -b source

Really, there are no special package managers just how you decide to implement them.
Quote:
Originally Posted by Plan9 View Post

Again, not an issue if you know what you're doing as if you're compiling your own stuff, then libs isn't an issue as you'd know to compile in the dependencies and keep them separate from the core libs. It's all stuff you'd expect a sys admin to know.

At that point you might as well chroot a system and run two "systems" inside each other, kind of like how we originally ran 32bit code. Yes I know, you aren't installing AS much crap, but honestly it still takes up dumb amounts of space if you do a lot of custom work. Not to mention you have to set up program specific perimeters, it's much easier re-compiling the system against new libs every time you update.
Quote:
Originally Posted by Plan9 View Post

It is bad practice to even have root login enabled, however plenty of sys admins do. But #9 was completely wrong when it kept arguing that X shouldn't be running as root. X must run as root (IIRC it's something to do with Xservers extensions not being kernel modules so it needs root to interface with the hardware). What they're talking about is Xsessions, which is an entirely different thing to running X-itself.

That is wrong. Xorg can be ran as any user, how the crap do you think startx works when you don't use a graphical login? It doesn't ask for root password, no prompts, yet it runs an entire DE as the user. That's weird, how on earth would that (could that) work? It does because xorg is designed to be ran regardless of the user, they have thought about sand boxing for years.


Ugh, there are more quotes and people I wanted to add per response but seroquel + booz = too freaking lazy.
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #46 of 51
Quote:
Originally Posted by mushroomboy View Post

At that point you might as well chroot a system and run two "systems" inside each other, kind of like how we originally ran 32bit code. Yes I know, you aren't installing AS much crap, but honestly it still takes up dumb amounts of space if you do a lot of custom work. Not to mention you have to set up program specific perimeters, it's much easier re-compiling the system against new libs every time you update.

Sometimes you need to.
Also chroot has nothing to do with this. What I'm talking about is having different versions of libraries installed and managed via environment variables - not jailing applications. You wouldn't really want to chroot any specific apps unless you were trying to sandbox it for security reasons, which is somewhat irrelevant to whether it was compiled from source or a decompressed binary.
Quote:
Originally Posted by mushroomboy View Post

That is wrong. Xorg can be ran as any user, how the crap do you think startx works when you don't use a graphical login? It doesn't ask for root password, no prompts, yet it runs an entire DE as the user. That's weird, how on earth would that (could that) work? It does because xorg is designed to be ran regardless of the user, they have thought about sand boxing for years.
Actually you can have applications run with root permissions even when launched by a user. In fact there's a few ways for passwordless permission elevation (passwordless entry in the sudoers file, setuid file permissions, scripts triggering daemons running as root, etc)

I can't comment if X has setuid permission or not, but it has been a known problem with Xorg requiring root for a long time. If that's now fixed, that's only happened within the last year; even as late as June 2010, Ubuntu hadn't shipped rootless Xorg: http://www.phoronix.com/scan.php?page=news_item&px=ODM2Ng

Or at the very least, if Xorg did previously run entirely as a non-root account, it would have been a limited Xsession (eg only support for software VESA modes).
Quote:
Originally Posted by mushroomboy View Post

Pacman doesn't do anything special, your pulled in by the AUR or ABS, pacman does nothing something like apt-get doesn't already do: apt-get -b source

Really, there are no special package managers just how you decide to implement them.
Actually pacman is a cut above most. What you've done there is compared pacman to the only other binary repository manager that's on a par (ie apt-get) and drew the conclusion that all package managers are much the same. I can assure you that they're really not. Personally I /hate/ RPM package managers and yet to find one with tools are are even half as good as pacman or apt-get. Even FreeBSD's binary repositories have a bit of a so-so package management (though their sources - /usr/ports - are amongst the best source managers out there).

Anyhow, all of this is besides the point as pacman doesn't manage source. Tools like yaourt manage source. In fact yaourt is a fantastic little tool - invaluable at times. But as you said, if AUR is holding broken source, then yaourt is just going to install broken packages (there's been more than a few occasions when I've needed to fix AUR install scripts and a couple of times I've needed to fix the source code itself!)
Edited by Plan9 - 1/31/12 at 5:27pm
post #47 of 51
Quote:
Originally Posted by Rookie1337 View Post

Interesting post...I'd laugh if someone calls themselves a "Linux admin" and has the same slowness of CLI that I have. I swear man and tab are the most common things I type up or hit when I'm in the CLI. That and cd or ls. I give props to the guys who can remember all of it. Hell I'm so lazy/bad that I use "*" when I want to install/move/delete things in CLI more than anyone should.
PS: Anyone got news on what's going to happen when/if Wayland comes? Is X going to be server only or is it going to be one for one replacement?

If you happen to be in a desktop environment then just set your wallpaper is a bunch of linux cli shortcuts. If you're in level 3 most of the time print it out or print a few out and just keep it handy. I can not remember every single command all the time either but the cheat sheets do help, I usually keep one in my laptop backpack for just in case on the road.
Quote:
Actually pacman is a cut above most. What you've done there is compared pacman to the only other binary repository manager that's on a par (ie apt-get) and drew the conclusion that all package managers are much the same. I can assure you that they're really not. Personally I /hate/ RPM package managers and yet to find one with tools are are even half as good as pacman or apt-get. Even FreeBSD's binary repositories have a bit of a so-so package management (though their sources - /usr/ports - are amongst the best source managers out there).

Anyhow, all of this is besides the point as pacman doesn't manage source. Tools like yaourt manage source. In fact yaourt is a fantastic little tool - invaluable at times. But as you said, if AUR is holding broken source, then yaourt is just going to install broken packages (there's been more than a few occasions when I've needed to fix AUR install scripts and a couple of times I've needed to fix the source code itself!)
Edited by Plan9 - Today at 7:27 pm

I do not know what it is about pacman but I find the commands to be the easiest to remember vs everything apt-get has. It's probably due to using Arch now for almost 3 years. I just installed Debian kfreebsd on my desktop and I am a bit lost in apt-get as of right now, it is also a HELL of a lot slower then pacman was/is.
Edited by Mr Pink57 - 1/31/12 at 9:13pm
post #48 of 51
In a way, the article is strange because it mentions points that I think are completely irrelevant. But maybe that's because when I think of "Linux admin", I think of a production server environment in a data center and not necessarily a office desktop environment.

1. Totally agree with this point. Always use a package management system if you have one and don't deviate outside of it. It's not a problem to install software that is not available in the standard software respositories, but in that case, you create packages out of the software and add your own repository. Anyone who doesn't understand this hasn't managed a large scale environment and have to develop a business continuity plan or recovery plan. When you're rebuilding 3000 servers in a new data center because your data center just got flooded, it's just too slow to recompile all sorts of software and rebuild the servers. What you want is pre-compiled respository of software that you can automatically pull packages from during your kickstart install of those 3000 servers. Any mid-level to senior level system admin should know how to build packages for the distributions or OSes they are responsible for; it's not a difficult skill to learn.

Those who say that a well versed Linux admin should know how to download tarballs and compile code and install, so this isn't a problem are missing the point; yes, that skill should be 2nd nature if you're an experienced Linux admin, but it's not an efficient way to manage servers and efficiency is very important when managing a large environment. The typical server-to-admin ratio for a large corporation should be higher than 300:1, and for homogeneous large environments, that ratio should be able to shoot up to 1000:1 if not higher. So, compiling software updates on all those servers per individual admin is a huge waste of time, what you want is to compile it once, build the package, deploy it and install the update (preferably through some automated system) fast.

Another point, that is related to the first point is documentation needs to be available on how those servers and applications are built and setup; and updated with the latest updates that are applied to the server. This type of information should also be in an asset management system so you can query what servers need to be patched when a security update is really critical and you need to figure out which of the several thousand servers need the security update and how to get that update out as fast as possible before some hacker is able to exploit any vulnerability.

2. updates should really be managed by an automated system. so, to me, more importantly is to put your servers under some automated patch management system which should then prevent the "neglect".

3. poor root password seems elementary. i only imagine the most jr of jr Linux admins doing this. some organizations don't even give their admins the root password and provide other auditable means to do system admin tasks; with only a handful of the most trusted persons with the root password which is highly guarded and very difficult to guess.

4. this is where i get really lost. other than some joe schmoe "playing" linux admin at home or perhaps on a closet server in some small business, I don't see GUI's installed on servers. So, if you don't have a GUI, how in the world can you do your job by avoiding the CLI? CLI is a must.... all those X libraries, desktop environments, and their dependencies just make for a lot of extra crap that needs to be patched, backed up, maintained, and risk exposure. Now, this might just be because in my mind I think of Linux admin as a server person.... but i guess if it's a Linux admin for an office desktop environment, that makes more sense to me. I have no experience managing a lot of desktops so I can't say anything more about that...

5. this sounds like a reasonable best practice... in the environments I work in, updates are often tested before they are applied and we can always pull downgrade packages if we need to back out an update.

6. again, this section confuses me because of the mention of the xorg.conf, which in my server environments don't even exist. But, yes, backups are extremely important. Moreover, having routine fire drills to restore from those backups are even more important. a backup is worthless if you can't actually restore from it. this ties back in to BCP and DR preparedness. good point, but the xorg.conf throws me off.

7. again, this totally throws me off too... none of the servers I manage have X installed at all. to me, in a server environment, this is irrelevant to even mention, it shouldn't be installed at all. desktop environment is a different story.

8. understanding permissions should be something even a jr linux admin should understand. if they don't understand this yet, then they are still in training and shouldn't be touching a production server environment. moreover, it is important to understand setuid, setgid, sticky bits, attributes, POSIX ACLs too...

9. most server environments implement this as a matter of policy and enforce it via configuration (such as blocking or disabling root login via SSH), so it's a good point, but not usually a mistake that can be made accidentally.

10. in a server environment, those logs should be sent to a central log processing center that scans the logs for problems and indications of a security breach that should then automatically alert the ops crew. highly recommended to move the logs off the server; many rootkits include tools to erase traces of the attacker from the log files; makes it much harder for them to do that if the logs are sent to a separate log server where they are processed quickly.

so, i guess there are some good points... the X stuff confuses me, but I often assume server environment and not desktop when I think of Linux sys admin... but i guess Linux admins for desktop environments may exist these days too...
TAIPEI
(10 items)
 
AURORA
(13 items)
 
 
MotherboardGraphicsRAMHard Drive
ASRock X99 Extreme11 EVGA GTX 980 Superclocked 32GB 8x4GB Corsair LPX Samsung XP941  
Hard DriveCoolingOSMonitor
Western Digital 3TB RE Noctua NH-D15 Fedora 21 Linux Samsung S27D590C 
PowerCase
Seasonic SS-1200XP Cooler Master Cosmos II 
CPUMotherboardGraphicsRAM
Dual Quad-core L5430 2.66Ghz 12mb cache Intel 5000 chipset ATI ES1000 64GB FBDIMM DDR2 PC2-5300 667Mhz 
Hard DriveOSPower
WD3000FYYZ PERC H700 w/ 512MB cache CentOS 7.2.1511 950W x2 
  hide details  
Reply
TAIPEI
(10 items)
 
AURORA
(13 items)
 
 
MotherboardGraphicsRAMHard Drive
ASRock X99 Extreme11 EVGA GTX 980 Superclocked 32GB 8x4GB Corsair LPX Samsung XP941  
Hard DriveCoolingOSMonitor
Western Digital 3TB RE Noctua NH-D15 Fedora 21 Linux Samsung S27D590C 
PowerCase
Seasonic SS-1200XP Cooler Master Cosmos II 
CPUMotherboardGraphicsRAM
Dual Quad-core L5430 2.66Ghz 12mb cache Intel 5000 chipset ATI ES1000 64GB FBDIMM DDR2 PC2-5300 667Mhz 
Hard DriveOSPower
WD3000FYYZ PERC H700 w/ 512MB cache CentOS 7.2.1511 950W x2 
  hide details  
Reply
post #49 of 51
Quote:
Originally Posted by Shrak View Post

You might not, but given the chance.... I so would. thumb.gif

Greetz
No you wouldn't and for exactly the reasons I used the analogy.

1)It would suck in the rain, snow, and heat

2) drive you broke in a hurry for fuel costs

3) You couldn't hear ur cell phone (or music) over the roar ; )

4) No trunk or passenger space

5) several other reasons (reliability, probably being number one), not the least of which it would be stolen in a heartbeat

In short it is not the right tool for the job since there is far more to getting to and/or around work than mere speed. To continue the car analogy, maybe I should have said you wouldn't buy and use a Ferrari in a Baja race. Servers don't require breakneck speed. Most require RAM, storage, security, and above all, stability. Period . Exclamation point.
NewMain
(16 items)
 
  
CPUMotherboardGraphicsRAM
Intel i5 - 3550 Asrock Z77 Extreme4 Gigabyte GTX 760  4x2GB Corsair Vengeance 
Hard DriveOptical DriveCoolingOS
Seagate SATA 2TB x 2  Plextor PX-891SAW CM-Hyper N520 Slackware 14, Studio KUbuntu, OpenSuSe 12.3, Wi... 
MonitorKeyboardPowerCase
32" Vizio HDTV + DLP Logitech Wireless Corsair HX-850 Antec Sonata I 
MouseMouse PadAudioOther
Razer DeathAdder 2013 dual ESI Juli@ CoolGear ExtSata Enclosure w/ Optical and 3TB S... 
  hide details  
Reply
NewMain
(16 items)
 
  
CPUMotherboardGraphicsRAM
Intel i5 - 3550 Asrock Z77 Extreme4 Gigabyte GTX 760  4x2GB Corsair Vengeance 
Hard DriveOptical DriveCoolingOS
Seagate SATA 2TB x 2  Plextor PX-891SAW CM-Hyper N520 Slackware 14, Studio KUbuntu, OpenSuSe 12.3, Wi... 
MonitorKeyboardPowerCase
32" Vizio HDTV + DLP Logitech Wireless Corsair HX-850 Antec Sonata I 
MouseMouse PadAudioOther
Razer DeathAdder 2013 dual ESI Juli@ CoolGear ExtSata Enclosure w/ Optical and 3TB S... 
  hide details  
Reply
post #50 of 51
Quote:
Originally Posted by enorbet2 View Post

Greetz
No you wouldn't and for exactly the reasons I used the analogy.
1)It would suck in the rain, snow, and heat
2) drive you broke in a hurry for fuel costs
3) You couldn't hear ur cell phone (or music) over the roar ; )
4) No trunk or passenger space
5) several other reasons (reliability, probably being number one), not the least of which it would be stolen in a heartbeat
In short it is not the right tool for the job since there is far more to getting to and/or around work than mere speed. To continue the car analogy, maybe I should have said you wouldn't buy and use a Ferrari in a Baja race. Servers don't require breakneck speed. Most require RAM, storage, security, and above all, stability. Period . Exclamation point.

I actually go to the drag strip in NC every weekend. I know drag cars pretty well tongue.gif

Now a Ferrari in a Baja race definitely wouldn't work, but being around Pungo Offroad... Oh would it be fun to jack up a Ferrari wheee.gif
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › 10 mistakes new Linux administrators make