![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
To get the most from this article, you should have experience working with desktop applications in a Windows environment. I assume readers have a basic understanding of how to use the Linux desktop. It's beneficial to have a working Linux computer to explore the concepts and examples in this article.
Sometimes running an application on Linux for the first time requires a
little extra work. Some applications such as server services might not be
installed as services, so you need to start those applications from the
command line. For the user accounts that start the applications,
set the execute permission flag (x)on the application files.
Running user-space applications
Linux runs processes in kernel space or user space. User space is the area of the operating system where applications typically run. Simply put, each user account has its own user space, and applications work within that realm.
Only the root user has access to kernel space by default. The root user is the superuser in Linux, comparable to the administrator account in Windows. Running an application under the root user account can pose a security risk and is not advisable.
Many server services need root permission to start the service. However, after the service is started, the root typically hands it off to a service account. Service accounts in Linux are technically standard user accounts. The primary difference is that service accounts are used only for running a service and aren't intended for anyone to actually log in with them.
You can set the execute permissions on a file with the
chmod command. The
umask setting in Linux typically prevents a
downloaded file from being executable, for good reason too because it can
help maintain the security of your Linux computer.
Most Linux distributions have a umask setting of
022, which means by default a new file has
permission settings of 644. The numeric
representation of permissions take the form of read (4), write (2), and
execute (1). So an application download with the default permission of
644 means the file owner has read and write
permission, while the group owner and other have read-only permission.
For example, to give everyone execute permission on a file, use the
chmod a+x command. The
a represents all, the plus sign
(+) represents add, and
x means execute. Likewise, if the
application is a server service, you should ensure only authorized
accounts have access to execute the service.
If an application is capable of running under standard user account permissions but only those in a particular group need access to use it, you can set the group owner permission to executable and add the users to a group.
Getting even more specific, you can also set access control list (ACL)
permissions on an executable file to allow a particular user or group the
permission to run the application. Use the
setfacl utility to set ACL permissions.
For those applications, such as server services, that need to start the process as root user, you have a few options. Table 1 summarizes various options that allow users to execute server services that require root privileges.
Table 1. Options to run applications that require root privileges
| Option | Description |
|---|---|
| As root user | Not recommended for server services. Acceptable for applications when users already know the root password and the compromise of the application is not a primary concern. |
SetUID | Not recommended due to security issues.
SetUID allows a standard user to
execute a file as another user, such as root. |
sudo | Commonly used and considered a good practice.
sudo grants a user or member of a group
permission to execute a file that would otherwise require root
privileges. The user does not need to know the root password. |
| Standard user account with file permissions | Set execute permission on a file for the user owner, group owner, or other (everyone). This is a common way to grant users who do not require root privileges permission to execute an application. |
| Standard user account with ACL permissions | Less commonly used, but a viable solution when you don't want to
grant a user sudo access or change the
permissions of a file. Using the
setfacl command on a file, you can
grant a particular user or group of users the right to execute the
file. |
Running an application from the command line is an essential task when managing Linux servers. A lot of applications have shell scripts—similar to Windows batch files (.bat)—that start the applications and perform other tasks such as setting variables and assigning processes to other users. For example, an application may need a Java™ Virtual Machine (JVM) to execute. In that case, shell scripts can set the appropriate environment variables and then execute the Java command to run the Java Archive (JAR) or class file. This holds true for applications using Perl, Python, and even C#. (Yes, C# compiled applications can run on Linux!)
You can execute a command from the command line or shell prompt with just the file name if the command is a part of the shell’s built in commands, or if the command’s directory location is included in the PATH variable. Commands such as "ls" and "cd" are examples of commands that are generally included in the PATH by default as they typically reside in the /usr/local/bin or /usr/bin directories. But if the file location is not set in the PATH, you must include the pathname to the file. For example, if the executable myapp resides in the /usr/share/scripts directory, type /usr/share/scripts/myapp to execute the script. You can also use the relative path by adding the dot (.) and slash (/) before the file name and type ./myapp. The dot (.) in the shell specifies the "current directory." (Windows includes the working directory on the execution path and some system administrators have been known to include the dot (.) in the PATH to emulate this, but this is not advisable for security reasons.) Likewise, you can precede the file name with the language environment such as:
- sh
- php
- python
- perl
- java
More often though, packaged applications have shell scripts that set the
environment variables and provide the runtime executable path of the language
with the #! symbol, such as
#!/usr/bin/python. You should become familiar
with this approach as well.
Listing 1 uses the
catalina.sh default script to start the Apache
Tomcat application server using the ./
approach. Then it starts the server using the
sh approach. Since the default port is 8080, no
special modifications are required to start the service as a standard
user.
Listing 1. Executing an application from the command line
$ ./catalina.sh start Using CATALINA_BASE: /opt/apache-tomcat-7.0.26 Using CATALINA_HOME: /opt/apache-tomcat-7.0.26 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/apache-tomcat-7.0.26/bin/bootstrap.jar: /opt/apache-tomcat-7.0.26/bin/tomcat-juli.jar $ ./catalina.sh stop ..................................................................... $ sh catalina.sh start Using CATALINA_BASE: /opt/apache-tomcat-7.0.26 Using CATALINA_HOME: /opt/apache-tomcat-7.0.26 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/apache-tomcat-7.0.26/bin/bootstrap.jar: /opt/apache-tomcat-7.0.26/bin/tomcat-juli.jar |
Consider starting a typical Hypertext Transfer Protocol (HTTP) web server. In Linux, any port less than port 1024 is considered a privileged port, and only root can open privileged ports. Because web servers by default run on port 80, root needs to start the process. As noted, however, it is considered insecure to run a service as the root user. The correct procedure is to start the service as root and then hand it off to a standard user or service account.
Fortunately, a lot of server services have the scripts in place to do just
that. If you build the Apache web server from source, you find it starts
as root and then hands off the httpd threads to the
apache user.
Listing 2 starts a default compilation of the Apache 2
web server. The install process does a few things, including making the
apachectl command executable. Because this
process requires use of port 80, it starts with root user privileges.
However, the ps command reveals the httpd
processes are running under the apache user account.
Listing 2. Starting the Apache web server
# cd /usr/local/apache2/bin # apachectl start #ps aux | grep httpd apache 23094 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23095 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23096 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23097 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23098 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start |
Running applications in the background
Some installed software might not be as user friendly as the Apache web server. Unless you are troubleshooting or otherwise want to see exactly what is going on with an application, you probably want to run it in the background after the process starts. If you don't, the application terminates when the shell is closed. When running server services, it's not desired behavior for the service to stop every time you close the terminal shell or otherwise log out!
If you run an application in the background, it continues to work even if
you close the shell window. You can start an application in the background
by appending an ampersand (&) at the end of
the execute command. For example, you can open a file with the vi editor
and run it in the background with the
vi /etc/sysconfig/network & command
because & opens the /etc/sysconfig/network
file and keeps it in the background. You can use the
nohup utility to allow the process to continue
even after you logout. For example,
nohup vi /etc/sysconfig/network &.
Listing 3 opens a file for editing in the Vim editor and places it in the background.
Listing 3. Running an application in the background
# vi /etc/sysconfig/network & [1] 24940 # jobs [1]+ Stopped vi /etc/sysconfig/network |
You can type the jobs command to see all the
applications you have running in the background. Each job running in the
background is assigned a sequential number, starting at 1. The job in
Listing 3 is job number 1.
24940 is the process ID (PID). You can bring an
application to the foreground with the fg
command and the specific job number. In this example, the process is not
in use by the user, so it displays as Stopped.
However, the command fg 1 opens the terminal
back to the active process of editing the file.
Running applications from the desktop
Running graphical user interface (GUI) applications from the desktop in Linux isn't much different from doing so in Windows. Mostly, you need to understand how applications are grouped in menus in your particular desktop environment. Linux has an abundance of desktop applications available for various tasks. Some are native to Linux, while others might be cross-platform applications developed with C# using a common runtime environment, just like .NET Framework applications. You might find that you can even run your favorite Windows application on Linux using a virtual environment such as Wine.
It's quite possible you'll find an alternative Linux application for your favorite Windows-based application. Running native Linux applications on the desktop is straightforward. Similar to Windows, you typically find these applications organized in menus, and you simply click and run as you would a Windows application.
For those applications that require root privileges, you are prompted to enter the root password before proceeding. This is similar in concept to the Run as Administrator option in Windows. Otherwise, all applications you run are in the user space of the account you are logged in to.
In Windows, you can create desktop shortcuts. Linux has similar shortcuts called launchers that you can place on the panel or desktop. When you click the launcher, it executes the program.
Figure 1 displays two launchers for the Mozilla Firefox web browser on the GNOME Desktop. One launcher is located on the panel, and the other is on the desktop.
Figure 1. Viewing launchers on the desktop and panel
Many Windows applications are developed using the .NET Framework. Mono is an open source implementation of .NET that runs on many platforms, including Linux. In fact, the Mono website describes it as an implementation of C# and the Common Language Runtime (CLR) that is binary compatible with .NET. The project is currently supported by Xamarin.
On Linux, you execute applications developed with the .NET framework (or
Mono) the same as you do on Windows. However, remember the Linux
umask and default file permissions. You still
need to provide execute permissions to the file so Linux will allow the
executable to perform.
Some cross-platform applications developed in Mono that you can install on your Linux GNOME desktop, such as F-Spot, reside on the menu with the native GNOME applications. F-Spot is an open source application for managing photos. Even though it is a C# application, it appears as a native application on the GNOME desktop. After you create a launcher for an application, you can click and run just like in Windows.
Figure 2 demonstrates the location of the Mono-based application, F-Spot, and how you can create desktop or panel launchers for it.
Figure 2. Creating a launcher for F-Spot
Wine lets you run Windows software on Linux and other operating systems. With Wine, you can install and run those applications just like you do in Windows. Wine is still under active development, and not all Windows programs work with Wine. If your application is compiled for a Windows operating system and you find it can run adequately using Wine, chances are it is a desktop application as opposed to a server application. Be sure to check the Wine documentation about the possibility of running the application on Linux because Wine doesn't fully support all applications.
When you use Wine with Linux, you have a hidden folder in your account home directory that emulates a Windows environment, as in Listing 4.
Listing 4. Wine's hidden folder that emulates a Windows environment
$ cd /home/tbost/.wine/drive_c/windows $ls cf8e.tmp command explorer.exe Fonts help hh.exe inf Installer ls.txt Microsoft.NET notepad.exe pwd.txt regedit.exe rundll.exe system system32 system.ini temp twain_32.dll twain.dll winhelp.exe winhlp32.exe win.ini winsxs |
After you install an application using Wine, you can typically find it on the desktop menu and run it the same way you would in Windows.
For example, Camstudio is an open source tool for recording and managing screen videos. Currently, there isn't a release for the Linux operating system. However, using Wine, I installed the Windows version on a Linux desktop. Wine-related applications are typically grouped under Applications > Wine > Programs, as in Figure 3.
Figure 3. Running a Windows application on Linux using Wine
While managing a Linux server, you are sure to encounter software that executes from the desktop and the command line. When you understand how to set the appropriate permissions and user accounts, you can securely run those applications. With long-running processes such as server services, you can execute from the command line and appropriately set in the background. If you have applications that are geared for running from the desktop, you can do that too—sometimes even Windows applications!
Learn
- Check out New to Linux programming and Linux system administration on developerWorks to learn more about getting started with Linux.
- Read Windows-to-Linux roadmap: Part 9. Installing software (Chris Walden, developerWorks, November 2003) to earn more about installing software on Linux.
- Learn more about DOS versus Linux commands.
- In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
- In the Open Source area on developerWorks, find extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Listen to developerWorks podcasts for interesting interviews and discussions for software developers.
- Follow developerWorks on Twitter.
- Watch developerWorks demos that range from product installation and setup for beginners to advanced functionality for experienced developers.
Get products and technologies
- Learn more about running Windows applications on Linux with Wine from the project website.
- Discover how to execute .NET framework applications on Linux with Mono from the project website.
- Access IBM trial software (available for download or on DVD) and innovate in your next open source development project using software especially for developers.
Discuss
- Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis. Help build the Real world open source group in the developerWorks community.
Tracy Bost is a seasoned software developer and systems engineer. He is also a lecturer and trainer for the Linux operating system. Tracy has been certified as both a Red Hat Certified Engineer (RHCE) and a Microsoft Certified Systems Engineer (MCSE), along with being an active member of the Linux Foundation. He has worked in several industries, including mortgage, real estate, and the nonprofit sector.
