Is command line sufficient enough for Linux administration?

[zhaogui]

I am new to Linux. Recently I noticed some Linux system administration tools are GUI-based, such as linuxconf, netcfg,etc. But my linux servers are inside DMZ, so I can't access these machines via Gui-based tools such as Exceed. May I know if command lines are sufficient enough to provide all system admin works?

Thanks,

[Stuart Browne]

Given nearly a decade of experience, half of which has been Linux and Unix admin..

HELL YES!

Gui for Administration is for those Windows people who don't know how to type a command with mroe than half a dozen options :)

Linuxconf and a number of other tools provide a text-based 'menu' interface (whcih is nice I admit) which doesn't require Gui (X) access.

Basically everything on a Unix/Linux system should be able to be done from a CLI. It will just mean you need to learn how some things work in more depth than you normally would have had to (from a GUI interface).

Linuxconf for instance doesn't provide you with any 'new' options which arn't already available from the command line. It just makes it easier to do.

On a RedHat system for instance, Linuxconf helps you drive the /etc/sysconfig/ structure (mostly), and a few other external daemons. A read of the documentation tells you what most of that can do and how it works.

A Gui is NOT a necesity for a *nix world.

If there is a specific function you need help with, there are a large number of people here are more than willing to help you (for a few points of course :P).

I hope this answers you question.. :)

[Heiner E. Lennackers]

As long as you are only administering the operation system, you do not need a gui (some distributions prefer a X-based install tool).
If you have to administer applications, you mey need a gui (oracle 8i, orsis, icemcfd etc have gui-based installers).

Heiner

[Alexander M. Ermes]

Hi there.
The commandline administration should be your first choice. Pushing around a mouse does not help you understand, what is really going on.
Debugging is much easier with a direct reply from the system than through a window with some weird error message, which you have to decrypt.
Rgds
Alexander M. Ermes

[Jeffrey S. Sims]

The command line is not only sufficient but it helps you to learn what is going on with the computer when you are troubleshooting. Command line is where your brain has to tell you what to do and where to find what you want, not some button that may or may not work.

So to answer your question with a short version:

YES

[Hal Rottenberg]

I'll go against the trend here a little bit. Yes, it is definitely sufficient and for many, superior. I'm not sure if its a left-brain / right-brain thing, but some people grasp concepts better visually in a way that can only be done in a GUI.

That having been said, my suggestion is to do a little of both. Use CLI, read manpages, get into writing scripts, it will only help your understanding of Linux. But sometimes you just need (as in Oracle) or want a GUI to do something.

For such a case, you may find it necessary and useful to change your firewall policies. If you can, open port 22 for SSH. It is widely viewed as a very secure terminal server and client and many use it exclusively instead of telnet. On top of that ssh can also establish an encrypted tcp tunnel like an ad hoc VPN session. It also has a feature made just for forwarding an X11 session across this connection. For more details see http://www.openssh.com/ or just install the openssh* packages and read the manpages. Depending on what distribution and install options you are running, you probably already have it. Try 'man ssh' and 'man sshd'.

And my second recommendation is to check out Webmin (http://www.webmin.com) or other web-based remote administration tools. Yes, it is important for you to know the doings behind the scene, but these other tools come in handy.

hope this helps

-hal

[Bill Thorsteinson]

Command line has always been sufficient for administration of linux. Some options are available from the GUI. All options are available from the command line.

The GUI does help for routine tasks involving several steps such as adding a user and setting up e-mail addresses. It is also a pain when it insist you must restart the network and all network based services because you added that user.

VNC works well if you can run it to allow GUI access through a firewall. You can set it up to accept incoming request, or to contact a viewer. It can also serve up a Java based viewer to a web browser. (On port 80 if you like use a negative screen number, -5720 I think). I use SSH to tunnel both X-Windows and VNC connections through firewalls.

[N.SivaramaKrishnan]

Of course _YES_, there is command line support for sys admin. You should rather practice with command line only rather than going for gui approach. Just type "linuxconf" in your command prompt and this given you a cursor based linuxconf same as u see with the GUI based.
GUI tools are only for _WINDOWS_ folks and being linux guy, we should use only command line commands rather than relying on GUI.

Hope I made sense.

Siva

[Magdi KAMAL]

Hi,

Normaly in unix and Linux world, commands are the basic interface to interact with the Operating System (OS). I would even say that all GUI are translating their interactions with users to Unix or Linux commands and only then it is executed.

So, don't worry about using commands. This could look more difficult in the first time but at least you are 100 % sure of what you are doing and specially mastering the interaction with the OS.

Some GUI will define their own tasks not basiclly on commands but on some specific executables which they develop by their own. In this case, the only way to use this functionnality is to use the GUI. so it depends !

Magdi

[Peter Kloetgen]

Hi Zhaogui,

yes, the answer must be YES!!

If you run a GUI, in background commands are executed like via the command line directly. The only extra a GUI can give to you, is that it "knows" the way how to execute the command, with which options and parameters and so on. If you know your needed commands and their options you are even much more powerful with command line than with GUIs. GUIs are allways standard products out of pocket, but your command line has much more possibilities which aren't even provided by the GUI.

So if you know your commands, you will never need a GUI!!

Allways stay on the bright side of life!

Peter

[Ron Kinner]

It had better be. I have Linux systems deployed all over Latin America and my only contact with them is via telnet.

Ron

[Kelli Ward]

Hi,
Here's another yes.
Command line administration is possible for virtually anything you will do as an administrator. GUI based administration is often easier because of point and click access but if you do not understand what the system is doing, you may be in real trouble if a GUI admin task fails.
Personally, I do quite a bit on the command line with the exception of printer management and user and group accounts. I have done it both ways and this is where the GUI interface is a real time saver. You might also consider (for those very repetitive tasks)writing shell scripts if GUI is unavailable.
For example, generating a user account takes about 7 full command line steps (depending on what unix-based OS you are using) on the command line. GUI based a few points and clicks and a little typing and a good shell scripts can be just as easy and can save you tons of time in the long run.
Best of luck to you,
Kel

[Mark Fenton]

The short answer, as all have attested, is a resounding "YES".

That said, I would also like to stick in my two cents for WEBMIN, which provides a very useable GUI administration interface, directable to any TCP port you would care to use.

(In general I use the command line in linux for most everything, with the exception of user administration, Samba, SQL Db's, Apache and Sendmail. All of which I *could* do via the command line, and often do, I just prefer to use the GUI for them)

Best Regards,
Mark

[zhaogui]

Thanks a lot. I am just wondering how come I can telnet indirectly to this Linux in DMZ through another machine, but I can't use xterm interface to do this in the same way? You see, even though I can connect to the machine using Exceed xterm, I still cannot run "export DISPLAY=mypc:0.0", because it is inside DMZ and can't ping to my PC. Anybody knows how I can do that?

Another question, if only ssh is allowed for me to connect indirectly to the Linux in DMZ, will I be able to use GUI via ssh, or is there built-in GUI feature provided by ssh?

[Stuart Browne]

Because you can't get a direct connetion (having to bounce through another machine), it would appear as if there is no way for you to talk directly too it, thus the X display wouldn't really be able to connect direclty to you (thus the Point of a DMZ).

As for the other however, I have read places where you can run X-Term's and other X based software via ssh (ssh after all allows you to EXECUTE a program on the remote machine, and spits the data back through the encrypted connection).

If you are only running an X-Term on the remote machine, then why don't you just (locally) execute 'xterm -rv -e ssh ' ? X-term it's self is run locally, but the content is (of course) from the remote machine. ?

(Also, don't forget to assign points to all those who have responded. It is a way to thank them for their time, and might well make people want to respond further in future.)

[zhaogui]

Thank you Stuart, but my problem is this remote Linux machine is in DMZ(let's called it node C). If I want to access C from my PC(node A), I have to go through this path: A(Win98)--->B(hp-ux)--->C(Linux), even node B only has dumb console. From A I can telnet to B first and then type "ssh C", so I am not sure how you can execute 'xterm -rv -e ssh C' on B and display the contents of C on my node A?

[zhaogui]

Thank you Stuart, but my problem is this remote Linux machine is in DMZ(let's called it node C). If I want to access C from my PC(node A), I have to go through this path: A(Win98)--->B(hp-ux)--->C(Linux), even node B only has dumb console. From A I can telnet to B first and then type "ssh C", so I am not sure how you can execute 'xterm -rv -e ssh C' on B and display the contents of C on my node A if you do not run "export DISPLAY=A:0.0" beforehand?
Because you know that "export DISPLAY..." on C doesn't work in my environment.

[Stuart Browne]

*nod* that makes a bit more sense as to what you are trying to do.

It sounds like you are running an X server on your own PC.

Given that situation, you should run an xterm on node 'b' (your HPUX machine) with a display set to node 'a' (your PC) which telnet's (or ssh's) to node 'c'.

I do exactally the same thing in my office here.

ie.

telnet nodeb

export DISPLAY=nodea:0.0
xterm -rv -e ssh nodec


You now have an X-Term window on your PC (node a) connected to the machine in the DMZ (node c), using the resources on node b to run the 'xterm' application. Welcome to the wonderful world of X-Windows :P

[zhaogui]

It sounds like a good idea, but it still cannot work. It still requires setup of DISPLAY. Here is the error after I run xterm -rv -e ssh -l myid nodec
nodec#netcfg
Traceback (innermost last):
File "/usr/lib/rhs/netcfg/netcfg.py", line 24, in ?
from rhtkinter import *
File "/usr/lib/rhs/python/rhtkinter.py", line 69, in ?
e = Entry()
File "/usr/lib/python1.5/lib-tk/Tkinter.py", line 1354, in __init__
Widget.__init__(self, master, 'entry', cnf, kw)
File "/usr/lib/python1.5/lib-tk/Tkinter.py", line 1078, in __init__
BaseWidget._setup(self, master, cnf)
File "/usr/lib/python1.5/lib-tk/Tkinter.py", line 1055, in _setup
_default_root = Tk()
File "/usr/lib/python1.5/lib-tk/Tkinter.py", line 886, in __init__
self.tk = _tkinter.create(screenName, baseName, className)
TclError: no display name and no $DISPLAY environment variable

If I set DISPLAY to my PC, then it just hangs there forever.

[Stuart Browne]

Ah. I didn't realise you were trying to launch other programs on nodec trying to attach to the X server on nodea.

This cannot be done given the topology of your network, and the DMZ.

You could try running a VNC server on nodec, and using vncclient on nodeb to view it on the X-server of nodea however..

Have you looked into VNC?

[zhaogui]

Are you refering VNC to Virtual Network Computing produced by AT&T? I searched the internet and found it out at http://www.uk.research.att.com/vnc/start.html. I am not sure how can this product perform such miracle to bypass DMZ and deliver GUI information all the way from nodeC to nodeB and to nodeA? What's the major difference between this product and Exceed? Do I need to change anything in the firewall?

[Stuart Browne]

I'm unsure whether Exceed has the ability to attach to run a virtual X-Server.

VNC's server can run with no physical display or video. It takes the signals sent to an X server, and has the ability to send them to a client.

The way it could circumvent the DMZ is by running the client on a machine which has access too it normally (your HPUX machine by your description).

As VNC (client) is an X application it's self, you can tell it's display to go anywehre you want, namely nodea.

I'm unsure however if there is a VNC client that runs on HPUX.

the VNC Server runs as a daemon (which you could firewall so only nodeb could access it) with the client connecting to a given virtual display from a remote location.

Using that, I attach to an X-server running on my PC at home.

NOTE: There are VNC servers which run on a variety of platforms, but.. that's no the issue here.

[Jason Sim]

I've had some similar problems in the past - it could be that your connection to NodeB is only a telnet connection, and is thus not encrypted, so there is not a full secure pipe from NodeC back to NodeA. Try using ssh to connect to NodeB as well from your local PC.