mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-25 00:50:15 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
commit
d0b9834024
@ -1,3 +1,5 @@
|
||||
Translating by MjSeven
|
||||
|
||||
How to install KVM on CentOS 7 / RHEL 7 Headless Server
|
||||
======
|
||||
|
||||
|
@ -1,234 +0,0 @@
|
||||
##amwps290 translating
|
||||
How to configure an Apache web server
|
||||
======
|
||||
|
||||

|
||||
|
||||
I have hosted my own websites for many years now. Since switching from OS/2 to Linux more than 20 years ago, I have used [Apache][1] as my server software. Apache is solid, well-known, and quite easy to configure for a basic installation. It is not really that much more difficult to configure for a more complex setup, such as multiple websites.
|
||||
|
||||
Installation and configuration of the Apache web server must be performed as root. Configuring the firewall also needs to be performed as root. Using a browser to view the results of this work should be done as a non-root user. (I use the useron `student` on my virtual host.)
|
||||
|
||||
### Installation
|
||||
|
||||
Note: I use a virtual machine (VM) using Fedora 27 with Apache 2.4.29. If you have a different distribution or a different release of Fedora, your commands and the locations and content of the configuration files may be different. However, the configuration lines you need to modify are the same.
|
||||
|
||||
The Apache web server is easy to install. On my CentOS 6.x server, it just takes a simple `yum` command. It installs all the necessary dependencies if any are missing. I used the `dnf` command below on one of my Fedora virtual machines. The syntax for `dnf` and `yum` are the same except for the name of the command itself.
|
||||
```
|
||||
dnf -y install httpd
|
||||
|
||||
```
|
||||
|
||||
The VM is a very basic desktop installation I am using as a testbed for writing a book. Even on this system, only six dependencies were installed in under a minute.
|
||||
|
||||
All the configuration files for Apache are located in `/etc/httpd/conf` and `/etc/httpd/conf.d`. The data for the websites is located in `/var/www` by default, but you can change that if you want.
|
||||
|
||||
### Configuration
|
||||
|
||||
The primary Apache configuration file is `/etc/httpd/conf/httpd.conf`. It contains a lot of configuration statements that don't need to be changed for a basic installation. In fact, only a few changes must be made to this file to get a basic website up and running. The file is very large so, rather than clutter this article with a lot of unnecessary stuff, I will show only those directives that you need to change.
|
||||
|
||||
First, take a bit of time and browse through the `httpd.conf` file to familiarize yourself with it. One of the things I like about Red Hat versions of most configuration files is the number of comments that describe the various sections and configuration directives in the files. The `httpd.conf` file is no exception, as it is quite well commented. Use these comments to understand what the file is configuring.
|
||||
|
||||
The first item to change is the `Listen` statement, which defines the IP address and port on which Apache is to listen for page requests. Right now, you just need to make this website available to the local machine, so use the `localhost` address. The line should look like this when you finish:
|
||||
```
|
||||
Listen 127.0.0.1:80
|
||||
|
||||
```
|
||||
|
||||
With this directive set to the IP address of the `localhost`, Apache will listen only for connections from the local host. If you want the web server to listen for connections from remote hosts, you would use the host's external IP address.
|
||||
|
||||
The `DocumentRoot` directive specifies the location of the HTML files that make up the pages of the website. That line does not need to be changed because it already points to the standard location. The line should look like this:
|
||||
```
|
||||
DocumentRoot "/var/www/html"
|
||||
|
||||
```
|
||||
|
||||
The Apache installation RPM creates the `/var/www` directory tree. If you wanted to change the location where the website files are stored, this configuration item is used to do that. For example, you might want to use a different name for the `www` subdirectory to make the identification of the website more explicit. That might look like this:
|
||||
```
|
||||
DocumentRoot "/var/mywebsite/html"
|
||||
|
||||
```
|
||||
|
||||
These are the only Apache configuration changes needed to create a simple website. For this little exercise, only one change was made to the `httpd.conf` file—the `Listen` directive. Everything else is already configured to produce a working web server.
|
||||
|
||||
One other change is needed, however: opening port 80 in our firewall. I use [iptables][2] as my firewall, so I change `/etc/sysconfig/iptables` to add a statement that allows HTTP protocol. The entire file looks like this:
|
||||
```
|
||||
# sample configuration for iptables service
|
||||
|
||||
# you can edit this manually or use system-config-firewall
|
||||
|
||||
# please do not ask us to add additional ports/services to this default configuration
|
||||
|
||||
*filter
|
||||
|
||||
:INPUT ACCEPT [0:0]
|
||||
|
||||
:FORWARD ACCEPT [0:0]
|
||||
|
||||
:OUTPUT ACCEPT [0:0]
|
||||
|
||||
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
|
||||
|
||||
-A INPUT -p icmp -j ACCEPT
|
||||
|
||||
-A INPUT -i lo -j ACCEPT
|
||||
|
||||
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
|
||||
|
||||
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
|
||||
|
||||
-A INPUT -j REJECT --reject-with icmp-host-prohibited
|
||||
|
||||
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
|
||||
|
||||
COMMIT
|
||||
|
||||
```
|
||||
|
||||
The line I added is the third from the bottom, which allows incoming traffic on port 80. Now I reload the altered iptables configuration.
|
||||
```
|
||||
[root@testvm1 ~]# cd /etc/sysconfig/ ; iptables-restore iptables
|
||||
|
||||
```
|
||||
|
||||
### Create the index.html file
|
||||
|
||||
The `index.html` file is the default file a web server will serve up when you access the website using just the domain name and not a specific HTML file name. In the `/var/www/html` directory, create a file with the name `index.html`. Add the content `Hello World`. You do not need to add any HTML markup to make this work. The sole job of the web server is to serve up a stream of text data, and the server has no idea what the date is or how to render it. It simply transmits the data stream to the requesting host.
|
||||
|
||||
After saving the file, set the ownership to `apache.apache`.
|
||||
```
|
||||
[root@testvm1 html]# chown apache.apache index.html
|
||||
|
||||
```
|
||||
|
||||
### Start Apache
|
||||
|
||||
Apache is very easy to start. Current versions of Fedora use `systemd`. Run the following commands to start it and then to check the status of the server:
|
||||
```
|
||||
[root@testvm1 ~]# systemctl start httpd
|
||||
|
||||
[root@testvm1 ~]# systemctl status httpd
|
||||
|
||||
● httpd.service - The Apache HTTP Server
|
||||
|
||||
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
|
||||
|
||||
Active: active (running) since Thu 2018-02-08 13:18:54 EST; 5s ago
|
||||
|
||||
Docs: man:httpd.service(8)
|
||||
|
||||
Main PID: 27107 (httpd)
|
||||
|
||||
Status: "Processing requests..."
|
||||
|
||||
Tasks: 213 (limit: 4915)
|
||||
|
||||
CGroup: /system.slice/httpd.service
|
||||
|
||||
├─27107 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
├─27108 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
├─27109 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
├─27110 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
└─27111 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
|
||||
|
||||
Feb 08 13:18:54 testvm1 systemd[1]: Starting The Apache HTTP Server...
|
||||
|
||||
Feb 08 13:18:54 testvm1 systemd[1]: Started The Apache HTTP Server.
|
||||
|
||||
```
|
||||
|
||||
The commands may be different on your server. On Linux systems that use SystemV start scripts, the commands would be:
|
||||
```
|
||||
[root@testvm1 ~]# service httpd start
|
||||
|
||||
Starting httpd: [Fri Feb 09 08:18:07 2018] [ OK ]
|
||||
|
||||
[root@testvm1 ~]# service httpd status
|
||||
|
||||
httpd (pid 14649) is running...
|
||||
|
||||
```
|
||||
|
||||
If you have a web browser like Firefox or Chrome on your host, you can use the URL `localhost` on the URL line of the browser to display your web page, simple as it is. You could also use a text mode web browser like [Lynx][3] to view the web page. First, install Lynx (if it is not already installed).
|
||||
```
|
||||
[root@testvm1 ~]# dnf -y install lynx
|
||||
|
||||
```
|
||||
|
||||
Then use the following command to display the web page.
|
||||
```
|
||||
[root@testvm1 ~]# lynx localhost
|
||||
|
||||
```
|
||||
|
||||
The result looks like this in my terminal session. I have deleted a lot of the empty space on the page.
|
||||
```
|
||||
Hello World
|
||||
|
||||
|
||||
|
||||
<snip>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Commands: Use arrow keys to move, '?' for help, 'q' to quit, '<-' to go back.
|
||||
|
||||
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
|
||||
|
||||
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list
|
||||
|
||||
```
|
||||
|
||||
Next, edit your `index.html` file and add a bit of HTML markup so it looks like this:
|
||||
```
|
||||
<h1>Hello World</h1>
|
||||
|
||||
```
|
||||
|
||||
Now refresh the browser. For Lynx, use the key combination Ctrl+R. The results look just a bit different. The text is in color, which is how Lynx displays headings if your terminal supports color, and it is now centered. In a GUI browser the text would be in a large font.
|
||||
```
|
||||
Hello World
|
||||
|
||||
|
||||
|
||||
<snip>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Commands: Use arrow keys to move, '?' for help, 'q' to quit, '<-' to go back.
|
||||
|
||||
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
|
||||
|
||||
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list
|
||||
|
||||
```
|
||||
|
||||
### Parting thoughts
|
||||
|
||||
As you can see from this little exercise, it is easy to set up an Apache web server. The specifics will vary depending upon your distribution and the version of Apache supplied by that distribution. In my environment, this was a pretty trivial exercise.
|
||||
|
||||
But there is more because Apache is very flexible and powerful. Next month I will discuss hosting multiple websites using a single instance of Apache.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/2/how-configure-apache-web-server
|
||||
|
||||
作者:[David Both][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/dboth
|
||||
[1]:https://httpd.apache.org/
|
||||
[2]:https://en.wikipedia.org/wiki/Iptables
|
||||
[3]:http://lynx.browser.org/
|
@ -0,0 +1,111 @@
|
||||
Protecting Code Integrity with PGP — Part 3: Generating PGP Subkeys
|
||||
======
|
||||

|
||||
|
||||
In this tutorial series, we're providing practical guidelines for using PGP. Previously, we provided an introduction to [basic tools and concepts][1], and we showed how to [generate and protect your master PGP key][2]. In this third article, we'll explain how to generate PGP subkeys, which are used in daily work.
|
||||
|
||||
### Checklist
|
||||
|
||||
1. Generate a 2048-bit Encryption subkey (ESSENTIAL)
|
||||
|
||||
2. Generate a 2048-bit Signing subkey (ESSENTIAL)
|
||||
|
||||
3. Generate a 2048-bit Authentication subkey (NICE)
|
||||
|
||||
4. Upload your public keys to a PGP keyserver (ESSENTIAL)
|
||||
|
||||
5. Set up a refresh cronjob (ESSENTIAL)
|
||||
|
||||
|
||||
|
||||
|
||||
#### Considerations
|
||||
|
||||
Now that we've created the master key, let's create the keys you'll actually be using for day-to-day work. We create 2048-bit keys because a lot of specialized hardware (we'll discuss this more later) does not handle larger keys, but also for pragmatic reasons. If we ever find ourselves in a world where 2048-bit RSA keys are not considered good enough, it will be because of fundamental breakthroughs in computing or mathematics and therefore longer 4096-bit keys will not make much difference.
|
||||
|
||||
##### Create the subkeys
|
||||
|
||||
To create the subkeys, run:
|
||||
```
|
||||
$ gpg --quick-add-key [fpr] rsa2048 encr
|
||||
$ gpg --quick-add-key [fpr] rsa2048 sign
|
||||
|
||||
```
|
||||
|
||||
You can also create the Authentication key, which will allow you to use your PGP key for ssh purposes:
|
||||
```
|
||||
$ gpg --quick-add-key [fpr] rsa2048 auth
|
||||
|
||||
```
|
||||
|
||||
You can review your key information using gpg --list-key [fpr]:
|
||||
```
|
||||
pub rsa4096 2017-12-06 [C] [expires: 2019-12-06]
|
||||
111122223333444455556666AAAABBBBCCCCDDDD
|
||||
uid [ultimate] Alice Engineer <alice@example.org>
|
||||
uid [ultimate] Alice Engineer <allie@example.net>
|
||||
sub rsa2048 2017-12-06 [E]
|
||||
sub rsa2048 2017-12-06 [S]
|
||||
|
||||
```
|
||||
|
||||
##### Upload your public keys to the keyserver
|
||||
|
||||
Your key creation is complete, so now you need to make it easier for others to find it by uploading it to one of the public keyservers. (Skip the step if you're not planning to actually use the key you've created, as this just litters keyservers with useless data.)
|
||||
```
|
||||
$ gpg --send-key [fpr]
|
||||
|
||||
```
|
||||
|
||||
If this command does not succeed, you can try specifying the keyserver on a port that is most likely to work:
|
||||
```
|
||||
$ gpg --keyserver hkp://pgp.mit.edu:80 --send-key [fpr]
|
||||
|
||||
```
|
||||
|
||||
Most keyservers communicate with each other, so your key information will eventually synchronize to all the others.
|
||||
|
||||
**Note on privacy:** Keyservers are completely public and therefore, by design, leak potentially sensitive information about you, such as your full name, nicknames, and personal or work email addresses. If you sign other people's keys or someone signs yours, keyservers will additionally become leakers of your social connections. Once such personal information makes it to the keyservers, it becomes impossible to edit or delete. Even if you revoke a signature or identity, that does not delete them from your key record, just marks them as revoked -- making them stand out even more.
|
||||
|
||||
That said, if you participate in software development on a public project, all of the above information is already public record, so making it additionally available via keyservers does not result in a net loss in privacy.
|
||||
|
||||
###### Upload your public key to GitHub
|
||||
|
||||
If you use GitHub in your development (and who doesn't?), you should upload your key following the instructions they have provided:
|
||||
|
||||
To generate the public key output suitable to paste in, just run:
|
||||
```
|
||||
$ gpg --export --armor [fpr]
|
||||
|
||||
```
|
||||
|
||||
##### Set up a refresh cronjob
|
||||
|
||||
You will need to regularly refresh your keyring to get the latest changes on other people's public keys. You can set up a cronjob to do that:
|
||||
```
|
||||
$ crontab -e
|
||||
|
||||
```
|
||||
|
||||
Add the following on a new line:
|
||||
```
|
||||
@daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
|
||||
|
||||
```
|
||||
|
||||
**Note:** Check the full path to your gpg or gpg2 command and use gpg2 if regular gpg for you is the legacy GnuPG v.1.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-3-generating-pgp-subkeys
|
||||
|
||||
作者:[Konstantin Ryabitsev][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/mricon
|
||||
[1]:https://www.linux.com/blog/learn/2018/2/protecting-code-integrity-pgp-part-1-basic-pgp-concepts-and-tools
|
||||
[2]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-2-generating-and-protecting-your-master-pgp-key
|
@ -0,0 +1,215 @@
|
||||
10 Quick Tips About sudo command for Linux systems
|
||||
======
|
||||
|
||||
![Linux-sudo-command-tips][1]
|
||||
|
||||
### Overview
|
||||
|
||||
**sudo** stands for **superuser do**. It allows authorized users to execute command as an another user. Another user can be regular user or superuser. However, most of the time we use it to execute command with elevated privileges.
|
||||
|
||||
sudo command works in conjunction with security policies, default security policy is sudoers and it is configurable via **/etc/sudoers** file. Its security policies are highly extendable. One can develop and distribute their own policies as plugins.
|
||||
|
||||
#### How it’s different than su
|
||||
|
||||
In GNU/Linux there are two ways to run command with elevated privileges:
|
||||
|
||||
* Using **su** command
|
||||
* Using **sudo** command
|
||||
|
||||
|
||||
|
||||
**su** stands for **switch user**. Using su, we can switch to root user and execute command. But there are few drawbacks with this approach.
|
||||
|
||||
* We need to share root password with another user.
|
||||
* We cannot give controlled access as root user is superuser
|
||||
* We cannot audit what user is doing.
|
||||
|
||||
|
||||
|
||||
sudo addresses these problems in unique way.
|
||||
|
||||
1. First of all, we don’t need to compromise root user password. Regular user uses its own password to execute command with elevated privileges.
|
||||
2. We can control access of sudo user meaning we can restrict user to execute only certain commands.
|
||||
3. In addition to this all activities of sudo user are logged hence we can always audit what actions were done. On Debian based GNU/Linux all activities are logged in **/var/log/auth.log** file.
|
||||
|
||||
|
||||
|
||||
Later sections of this tutorial sheds light on these points.
|
||||
|
||||
#### Hands on with sudo
|
||||
|
||||
Now, we have fair understanding about sudo. Let us get our hands dirty with practical. For demonstration, I am using Ubuntu. However, behavior with another distribution should be identical.
|
||||
|
||||
#### Allow sudo access
|
||||
|
||||
Let us add regular user as a sudo user. In my case user’s name is linuxtechi
|
||||
|
||||
1) Edit /etc/sudoers file as follows:
|
||||
```
|
||||
$ sudo visudo
|
||||
|
||||
```
|
||||
|
||||
2) Add below line to allow sudo access to user linuxtechi:
|
||||
```
|
||||
linuxtechi ALL=(ALL) ALL
|
||||
|
||||
```
|
||||
|
||||
In above command:
|
||||
|
||||
* linuxtechi indicates user name
|
||||
* First ALL instructs to permit sudo access from any terminal/machine
|
||||
* Second (ALL) instructs sudo command to be allowed to execute as any user
|
||||
* Third ALL indicates all command can be executed as root
|
||||
|
||||
|
||||
|
||||
#### Execute command with elevated privileges
|
||||
|
||||
To execute command with elevated privileges, just prepend sudo word to command as follows:
|
||||
```
|
||||
$ sudo cat /etc/passwd
|
||||
|
||||
```
|
||||
|
||||
When you execute this command, it will ask linuxtechi’s password and not root user password.
|
||||
|
||||
#### Execute command as an another user
|
||||
|
||||
In addition to this we can use sudo to execute command as another user. For instance, in below command, user linuxtechi executes command as a devesh user:
|
||||
```
|
||||
$ sudo -u devesh whoami
|
||||
[sudo] password for linuxtechi:
|
||||
devesh
|
||||
|
||||
```
|
||||
|
||||
#### Built in command behavior
|
||||
|
||||
One of the limitation of sudo is – Shell’s built in command doesn’t work with it. For instance, history is built in command, if you try to execute this command with sudo then command not found error will be reported as follows:
|
||||
```
|
||||
$ sudo history
|
||||
[sudo] password for linuxtechi:
|
||||
sudo: history: command not found
|
||||
|
||||
```
|
||||
|
||||
**Access root shell**
|
||||
|
||||
To overcome above problem, we can get access to root shell and execute any command from there including Shell’s built in.
|
||||
|
||||
To access root shell, execute below command:
|
||||
```
|
||||
$ sudo bash
|
||||
|
||||
```
|
||||
|
||||
After executing this command – you will observe that prompt sign changes to pound (#) character.
|
||||
|
||||
### Recipes
|
||||
|
||||
In this section we’ll discuss some useful recipes which will help you to improve productivity. Most of the commands can be used to complete day-to-day task.
|
||||
|
||||
#### Execute previous command as a sudo user
|
||||
|
||||
Let us suppose you want to execute previous command with elevated privileges, then below trick will be useful:
|
||||
```
|
||||
$ sudo !4
|
||||
|
||||
```
|
||||
|
||||
Above command will execute 4th command from history with elevated privileges.
|
||||
|
||||
#### sudo command with Vim
|
||||
|
||||
Many times we edit system’s configuration files and while saving we realize that we need root access to do this. Because this we may lose our changes. There is no need to get panic, we can use below command in Vim to rescue from this situation:
|
||||
```
|
||||
:w !sudo tee %
|
||||
|
||||
```
|
||||
|
||||
In above command:
|
||||
|
||||
* Colon (:) indicates we are in Vim’s ex mode
|
||||
* Exclamation (!) mark indicates that we are running shell command
|
||||
* sudo and tee are the shell commands
|
||||
* Percentage (%) sign indicates all lines from current line
|
||||
|
||||
|
||||
|
||||
#### Execute multiple commands using sudo
|
||||
|
||||
So far we have executed only single command with sudo but we can execute multiple commands with it. Just separate commands using semicolon (;) as follows:
|
||||
```
|
||||
$ sudo -- bash -c 'pwd; hostname; whoami'
|
||||
|
||||
```
|
||||
|
||||
In above command:
|
||||
|
||||
* Double hyphen (–) stops processing of command line switches
|
||||
* bash indicates shell name to be used for execution
|
||||
* Commands to be executed are followed by –c option
|
||||
|
||||
|
||||
|
||||
#### Run sudo command without password
|
||||
|
||||
When sudo command is executed first time then it will prompt for password and by default password will be cached for next 15 minutes. However, we can override this behavior and disable password authentication using NOPASSWD keyword as follows:
|
||||
```
|
||||
linuxtechi ALL=(ALL) NOPASSWD: ALL
|
||||
|
||||
```
|
||||
|
||||
#### Restrict user to execute certain commands
|
||||
|
||||
To provide controlled access we can restrict sudo user to execute only certain commands. For instance, below line allows execution of echo and ls commands only
|
||||
```
|
||||
linuxtechi ALL=(ALL) NOPASSWD: /bin/echo /bin/ls
|
||||
|
||||
```
|
||||
|
||||
#### Insights about sudo
|
||||
|
||||
Let us dig more about sudo command to get insights about it.
|
||||
```
|
||||
$ ls -l /usr/bin/sudo
|
||||
-rwsr-xr-x 1 root root 145040 Jun 13 2017 /usr/bin/sudo
|
||||
|
||||
```
|
||||
|
||||
If you observe file permissions carefully, **setuid** bit is enabled on sudo. When any user runs this binary it will run with the privileges of the user that owns the file. In this case it is root user.
|
||||
|
||||
To demonstrate this, we can use id command with it as follows:
|
||||
```
|
||||
$ id
|
||||
uid=1002(linuxtechi) gid=1002(linuxtechi) groups=1002(linuxtechi)
|
||||
|
||||
```
|
||||
|
||||
When we execute id command without sudo then id of user linuxtechi will be displayed.
|
||||
```
|
||||
$ sudo id
|
||||
uid=0(root) gid=0(root) groups=0(root)
|
||||
|
||||
```
|
||||
|
||||
But if we execute id command with sudo then id of root user will be displayed.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Takeaway from this article is – sudo provides more controlled access to regular users. Using these techniques multiple users can interact with GNU/Linux in secure manner.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linuxtechi.com/quick-tips-sudo-command-linux-systems/
|
||||
|
||||
作者:[Pradeep Kumar][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linuxtechi.com/author/pradeep/
|
||||
[1]:https://www.linuxtechi.com/wp-content/uploads/2018/03/Linux-sudo-command-tips.jpg
|
@ -0,0 +1,81 @@
|
||||
5 open source software tools for supply chain management
|
||||
======
|
||||
|
||||

|
||||
|
||||
This article was originally posted on January 14, 2016, and last updated March 2, 2018.
|
||||
|
||||
If you manage a business that deals with physical goods, [supply chain management][1] is an important part of your business process. Whether you're running a tiny Etsy store with just a few customers, or a Fortune 500 manufacturer or retailer with thousands of products and millions of customers worldwide, it's important to have a close understanding of your inventory and the parts and raw materials you need to make your products.
|
||||
|
||||
Keeping track of physical items, suppliers, customers, and all the many moving parts associated with each can greatly benefit from, and in some cases be totally dependent on, specialized software to help manage these workflows. In this article, we'll take a look at some free and open source software options for supply chain management and some of the features of each.
|
||||
|
||||
Supply chain management goes a little further than just inventory management. It can help you keep track of the flow of goods to reduce costs and plan for scenarios in which the supply chain could change. It can help you keep track of compliance issues, whether these fall under the umbrella of legal requirements, quality minimums, or social and environmental responsibility. It can help you plan the minimum supply to keep on hand and enable you to make smart decisions about order quantities and delivery times.
|
||||
|
||||
Because of its nature, a lot of supply chain management software is bundled with similar software, such as [customer relationship management][2] (CRM) and [enterprise resource planning][3] (ERP) tools. So, when making a decision about which tool is best for your organization, you may wish to consider integration with other tools as a part of your decision-making criteria.
|
||||
|
||||
### Apache OFBiz
|
||||
|
||||
[Apache OFBiz][4] is a suite of related tools for helping you manage a variety of business processes. While it can manage a variety of related issues like catalogs, e-commerce sites, accounting, and point of sale, its primary supply chain functions focus on warehouse management, fulfillment, order, and manufacturing management. It is very customizable, but the flip side of that is that it requires a good deal of careful planning to set up and integrate with your existing processes. That's one reason it is probably the best fit for a midsize to large operation. The project's functionality is built across three layers: presentation, business, and data, making it a scalable solution, but again, a complex one.
|
||||
|
||||
The source code of Apache OFBiz can be found in the [project's repository][5]. Apache OFBiz is written in Java and is licensed under an [Apache 2.0 license][6].
|
||||
|
||||
If this looks interesting, you might also want to check out [opentaps][7], which is built on top of OFBiz. Opentaps enhances OFBiz's user interface and adds core ERP and CRM features, including warehouse management, purchasing, and planning. It's licensed under [AGPL 3.0][8], with a commercial license available for organizations that don't want to be bound by the open source license.
|
||||
|
||||
### OpenBoxes
|
||||
|
||||
[OpenBoxes][9] is a supply chain management and inventory control project, primarily and originally designed for keeping track of pharmaceuticals in a healthcare environment, but it can be modified to track any type of stock and the flows associated with it. It has tools for demand forecasting based on historical order quantities, tracking stock, supporting multiple facilities, expiration date tracking, kiosk support, and many other features that make it ideal for healthcare situations, but could also be useful for other industries.
|
||||
|
||||
Available under an [Eclipse Public License][10], OpenBoxes is written primarily in Groovy and its source code can be browsed on [GitHub][11].
|
||||
|
||||
### OpenLMIS
|
||||
|
||||
Like OpenBoxes, [OpenLMIS][12] is a supply chain management tool for the healthcare sector, but it was specifically designed for use in low-resource areas in Africa to ensure medications and medical supplies get to patients in need. Its API-driven approach enables users to customize and extend OpenLMIS while maintaining a connection to the common codebase. It was developed with funding from the Rockefeller Foundation, and other contributors include the UN, USAID, and the Bill & Melinda Gates Foundation.
|
||||
|
||||
OpenLMIS is written in Java and JavaScript with AngularJS. It is available under an [AGPL 3.0 license][13], and its source code is accessible on [GitHub][13].
|
||||
|
||||
### Odoo
|
||||
|
||||
You might recognize [Odoo][14] from our previous top [ERP projects][3] article. In fact, a full ERP may be a good fit for you, depending on your needs. Odoo's supply chain management tools mostly revolve around inventory and purchase management, as well as connectivity with e-commerce and point of sale, but it can also connect to other tools like [frePPLe][15] for open source production planning.
|
||||
|
||||
Odoo is available both as a software-as-a-service solution and an open source community edition. The open source edition is released under [LGPL][16] version 3, and the source is available on [GitHub][17]. Odoo is primarily written in Python.
|
||||
|
||||
### xTuple
|
||||
|
||||
Billing itself as "supply chain management software for growing businesses," [xTuple][18] focuses on businesses that have outgrown their conventional small business ERP and CRM solutions. Its open source version, called Postbooks, adds some inventory, distribution, purchasing, and vendor reporting features to its core accounting, CRM, and ERP capabilities, and a commercial version expands the [features][19] for manufacturers and distributors.
|
||||
|
||||
xTuple is available under the Common Public Attribution License ([CPAL][20]), and the project welcomes developers to fork it to create other business software for inventory-based manufacturers. Its web app core is written in JavaScript, and its source code can be found on [GitHub][21].
|
||||
|
||||
There are, of course, other open source tools that can help with supply chain management. Know of a good one that we left off? Let us know in the comments below.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/tools/supply-chain-management
|
||||
|
||||
作者:[Jason Baker][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/jason-baker
|
||||
[1]:https://en.wikipedia.org/wiki/Supply_chain_management
|
||||
[2]:https://opensource.com/business/14/7/top-5-open-source-crm-tools
|
||||
[3]:https://opensource.com/resources/top-4-open-source-erp-systems
|
||||
[4]:http://ofbiz.apache.org/
|
||||
[5]:http://ofbiz.apache.org/source-repositories.html
|
||||
[6]:http://www.apache.org/licenses/LICENSE-2.0
|
||||
[7]:http://www.opentaps.org/
|
||||
[8]:http://www.fsf.org/licensing/licenses/agpl-3.0.html
|
||||
[9]:http://openboxes.com/
|
||||
[10]:http://opensource.org/licenses/eclipse-1.0.php
|
||||
[11]:https://github.com/openboxes/openboxes
|
||||
[12]:http://openlmis.org/
|
||||
[13]:https://github.com/OpenLMIS/openlmis-ref-distro/blob/master/LICENSE
|
||||
[14]:https://www.odoo.com/
|
||||
[15]:https://frepple.com/
|
||||
[16]:https://github.com/odoo/odoo/blob/9.0/LICENSE
|
||||
[17]:https://github.com/odoo/odoo
|
||||
[18]:https://xtuple.com/
|
||||
[19]:https://xtuple.com/comparison-chart
|
||||
[20]:https://xtuple.com/products/license-options#cpal
|
||||
[21]:http://xtuple.github.io/
|
@ -0,0 +1,170 @@
|
||||
How to manage your workstation configuration with Ansible
|
||||
======
|
||||
|
||||

|
||||
|
||||
Configuration management is a very important aspect of both server administration and DevOps. The "infrastructure as code" methodology makes it easy to deploy servers in various configurations and dynamically scale an organization's resources to keep up with user demands. But less attention is paid to individual administrators who want to automate the setup of their own laptops and desktops (workstations).
|
||||
|
||||
In this series, I'll show you how to automate your workstation setup via [Ansible][1] , which will allow you to easily restore your entire configuration if you want or need to reload your machine. In addition, if you have multiple workstations, you can use this same approach to make the configuration identical on each. In this first article, we'll set up basic configuration management for our personal or work computers and set the foundation for the rest of the series. By the end of this article, you'll have a working setup to benefit from right away. Each article will automate more things and grow in complexity.
|
||||
|
||||
### Why Ansible?
|
||||
|
||||
Many configuration management solutions are available, including Salt Stack, Chef, and Puppet. I prefer Ansible because it's lighter in terms of resource utilization, its syntax is easier to read, and when harnessed properly it can revolutionize your configuration management. Ansible's lightweight nature is especially relevant to the topic at hand, because we may not want to run an entire server just to automate the setup of our laptops and desktops. Ideally, we want something fast; something we can use to get up and running quickly should we need to restore our workstations or synchronize our configuration between multiple machines. My specific method for Ansible (which I'll demonstrate in this article) is perfect for this—there's no server to maintain. You just download your configuration and run it.
|
||||
|
||||
### My approach
|
||||
|
||||
Typically, Ansible is run from a central server. It utilizes an inventory file, which is a text file that contains a list of all the hosts and their IP addresses or domain names we want Ansible to manage. This is great for static environments, but it is not ideal for workstations. The reason being we really don't know what the status of our workstations will be at any one moment. Perhaps I powered down my desktop or my laptop may be suspended and stowed in my bag. In either case, the Ansible server would complain, as it can't reach my machines if they are offline. We need something that's more of an on-demand approach, and the way we'll accomplish that is by utilizing `ansible-pull`. The `ansible-pull` command, which is part of Ansible, allows you to download your configuration from a Git repository and apply it immediately. You won't need to maintain a server or an inventory list; you simply run the `ansible-pull` command, feed it a Git repository URL, and it will do the rest for you.
|
||||
|
||||
### Getting started
|
||||
|
||||
First, install Ansible on the computer you want it to manage. One problem is that a lot of distributions ship with an older version. I can tell you from experience you'll definitely want the latest version available. New features are introduced into Ansible quite frequently, and if you're running an older version, example syntax you find online may not be functional because it's using features that aren't implemented in the version you have installed. Even point releases have quite a few new features. One example of this is the `dconf` module, which is new to Ansible as of 2.4. If you try to utilize syntax that makes use of this module, unless you have 2.4 or newer it will fail. In Ubuntu and its derivatives, we can easily install the latest version of Ansible with the official personal package archive ([PPA][2]). The following commands will do the trick:
|
||||
```
|
||||
sudo apt-get install software-properties-common
|
||||
|
||||
sudo apt-add-repository ppa:ansible/ansible
|
||||
|
||||
sudo apt-get update
|
||||
|
||||
sudo apt-get install ansible
|
||||
|
||||
```
|
||||
|
||||
If you're not using Ubuntu, [consult Ansible's documentation][3] on how to obtain it for your platform.
|
||||
|
||||
Next, we'll need a Git repository to hold our configuration. The easiest way to satisfy this requirement is to create an empty repository on GitHub, or you can utilize your own Git server if you have one. To keep things simple, I'll assume you're using GitHub, so adjust the commands if you're using something else. Create a repository in GitHub; you'll end up with a repository URL that will be similar to this:
|
||||
```
|
||||
git@github.com:<your_user_name>/ansible.git
|
||||
|
||||
```
|
||||
|
||||
Clone that repository to your local working directory (ignore any message that complains that the repository is empty):
|
||||
```
|
||||
git clone git@github.com:<your_user_name>/ansible.git
|
||||
|
||||
```
|
||||
|
||||
Now we have an empty repository we can work with. Change your working directory to be inside the repository (`cd ./ansible` for example) and create a file named `local.yml` in your favorite text editor. Place the following configuration in that file:
|
||||
```
|
||||
- hosts: localhost
|
||||
|
||||
become: true
|
||||
|
||||
tasks:
|
||||
|
||||
- name: Install htop
|
||||
|
||||
apt: name=htop
|
||||
|
||||
```
|
||||
|
||||
The file you just created is known as a **playbook** , and the instruction to install `htop` (a package I arbitrarily picked to serve as an example) is known as a **play**. The playbook itself is a file in the YAML format, which is a simple to read markup language. A full walkthrough of YAML is beyond the scope of this article, but you don't need to have an expert understanding of it to be proficient with Ansible. The configuration is easy to read; by simply looking at this file, you can easily glean that we're installing the `htop` package. Pay special attention to the `apt` module on the last line, which will only work on Debian-based systems. You can change this to `yum` instead of `apt` if you're using a Red Hat platform or change it to `dnf` if you're using Fedora. The `name` line simply gives information regarding our task and will be shown in the output. Therefore, you'll want to make sure the name is descriptive so it's easy to find if you need to troubleshoot multiple plays.
|
||||
|
||||
Next, let's commit our new file to our repository:
|
||||
```
|
||||
git add local.yml
|
||||
|
||||
git commit -m "initial commit"
|
||||
|
||||
git push origin master
|
||||
|
||||
```
|
||||
|
||||
Now our new playbook should be present in our repository on GitHub. We can apply the playbook we created with the following command:
|
||||
```
|
||||
sudo ansible-pull -U https://github.com/<your_user_name>/ansible.git
|
||||
|
||||
```
|
||||
|
||||
If executed properly, the `htop` package should be installed on your system. You might've seen some warnings near the beginning that complain about the lack of an inventory file. This is fine, as we're not using an inventory file (nor do we need to for this use). At the end of the output, it will give you an overview of what it did. If `htop` was installed properly, you should see `changed=1` on the last line of the output.
|
||||
|
||||
How did this work? The `ansible-pull` command uses the `-U` option, which expects a repository URL. I gave it the `https` version of the repository URL for security purposes because I don't want any hosts to have write access back to the repository (`https` is read-only by default). The `local.yml` playbook name is assumed, so we didn't need to provide a filename for the playbook—it will automatically run a playbook named `local.yml` if it finds it in the repository's root. Next, we used `sudo` in front of the command since we are modifying the system.
|
||||
|
||||
Let's go ahead and add additional packages to our playbook. I'll add two additional packages so that it looks like this:
|
||||
```
|
||||
- hosts: localhost
|
||||
|
||||
become: true
|
||||
|
||||
tasks:
|
||||
|
||||
- name: Install htop
|
||||
|
||||
apt: name=htop
|
||||
|
||||
|
||||
|
||||
- name: Install mc
|
||||
|
||||
apt: name=mc
|
||||
|
||||
|
||||
|
||||
- name: Install tmux
|
||||
|
||||
apt: name=tmux
|
||||
|
||||
```
|
||||
|
||||
I added additional plays (tasks) for installing two other packages, `mc` and `tmux`. It doesn't matter what packages you choose to have this playbook install; I just picked these arbitrarily. You should install whichever packages you want all your systems to have. The only caveat is that you have to know that the packages exist in the repository for your distribution ahead of time.
|
||||
|
||||
Before we commit and apply this updated playbook, we should clean it up. It will work fine as it is, but (to be honest) it looks kind of messy. Let's try installing all three packages in just one play. Replace the contents of your `local.yml` with this:
|
||||
```
|
||||
- hosts: localhost
|
||||
|
||||
become: true
|
||||
|
||||
tasks:
|
||||
|
||||
- name: Install packages
|
||||
|
||||
apt: name={{item}}
|
||||
|
||||
with_items:
|
||||
|
||||
- htop
|
||||
|
||||
- mc
|
||||
|
||||
- tmux
|
||||
|
||||
```
|
||||
|
||||
Now that looks cleaner and more efficient. We used `with_items` to consolidate our package list into one play. If we want to add additional packages, we simply add another line with a hyphen and a package name. Consider `with_items` to be similar to a `for` loop. Every package we list will be installed.
|
||||
|
||||
Commit our new changes back to the repository:
|
||||
```
|
||||
git add local.yml
|
||||
|
||||
git commit -m "added additional packages, cleaned up formatting"
|
||||
|
||||
git push origin master
|
||||
|
||||
```
|
||||
|
||||
Now we can run our playbook to benefit from the new configuration:
|
||||
```
|
||||
sudo ansible-pull -U https://github.com/<your_user_name>/ansible.git
|
||||
|
||||
```
|
||||
|
||||
Admittedly, this example doesn't do much yet; all it does is install a few packages. You could've installed these packages much faster just using your package manager. However, as this series continues, these examples will become more complex and we'll automate more things. By the end, the Ansible configuration you'll create will automate more and more tasks. For example, the one I use automates the installation of hundreds of packages, sets up `cron` jobs, handles desktop configuration, and more.
|
||||
|
||||
From what we've accomplished so far, you can probably already see the big picture. All we had to do was create a repository, put a playbook in that repository, then utilize the `ansible-pull` command to pull down that repository and apply it to our machine. We didn't need to set up a server. In the future, if we want to change our config, we can pull down the repo, update it, then push it back to our repository and apply it. If we're setting up a new machine, we only need to install Ansible and apply the configuration.
|
||||
|
||||
In the next article, we'll automate this even further via `cron` and some additional items. In the meantime, I've copied the code for this article into [my GitHub repository][4] so you can check your syntax against mine. I'll update the code as we go along.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/manage-workstation-ansible
|
||||
|
||||
作者:[Jay LaCroix][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/jlacroix
|
||||
[1]:https://www.ansible.com/
|
||||
[2]:https://launchpad.net/ubuntu/+ppas
|
||||
[3]:http://docs.ansible.com/ansible/latest/intro_installation.html
|
||||
[4]:https://github.com/jlacroix82/ansible_article
|
@ -0,0 +1,246 @@
|
||||
# 配置 Apache Web 服务器
|
||||
|
||||

|
||||
|
||||
我自己的网站已经有很多年了。自从 20 多年前从 OS/2 切换到 Linux 以来,我已经将 [Apache][1] 作为我的服务器软件。Apache 是可靠的、众所周知的,并且基本的安装配置也很容易。对于更复杂的设置(比如多个网站)并不是那么困难。
|
||||
|
||||
Apache Web 服务器的安装和配置必须以 root 身份执行。 防火墙的配置也需要以 root 身份执行。 使用浏览器查看安装配置的结果应该以非 root 用户的身份完成。 (我在我的虚拟主机上使用 `student` 这个用户。)
|
||||
|
||||
### 安装
|
||||
|
||||
注意:我使用的实验环境是安装有 Fedora 27 的虚拟机,Apache 版本为 2.4.29。 如果您使用的是不同的发行版或不同版本的Fedora,您的命令以及配置文件的位置和内容可能会有所不同。 但是,您需要修改的配置行是相同的。
|
||||
|
||||
Apache Web 服务器非常容易安装。 在我的 CentOS 6.x 服务器上,它只需要一个简单的 `yum` 命令。 它会安装所有必要的依赖(如果需要的话)。 我在我的 Fedora 虚拟机上使用了下面的 `dnf` 命令。 除了命令本身的名称之外, `dnf` 和 `yum` 的语法是相同的。
|
||||
|
||||
```
|
||||
dnf -y install httpd
|
||||
|
||||
```
|
||||
|
||||
VM (虚拟机) 非常容易安装,我正在使用它作为编写书籍的测试平台。 即使在这个系统上,在一分钟内只安装了六个依赖项。
|
||||
|
||||
Apache 的所有配置文件都位于 `/etc/httpd/conf` 和 `/etc/httpd/conf.d` 。网站的数据默认位于 `/var/www`,但如果你愿意,你可以改变它。
|
||||
|
||||
### 配置
|
||||
|
||||
Apache 主要的配置文件是 `/etc/httpd/conf/httpd.conf` 。 它包含许多在基本安装中不需要更改的配置。 实际上,只需对此文件进行一些更改即可启动并运行一个简单的网站。 该文件非常大,因此,我不会将这篇文章与大量不必要的东西混淆起来,而只会显示那些需要更改的指令。
|
||||
|
||||
首先,花点时间熟悉一下 `httpd.conf` 文件。我喜欢 Red Hat 的一个原因是它的配置文件注释非常的详细。 `httpd.conf` 文件也不例外,因为它有很好的注释。 使用这些注释来了解文件的配置。
|
||||
|
||||
第一个要修改的是 `Listen` 配置项,它定义了 Apache 要监听页面请求的 IP 地址和端口。 现在,你只需要使这个网站可以从本地访问,所以使用 `localhost` 地址。 完成后,该行应该看起来像这样:( LCTT 注:localhost 既是 127.0.0.1,80 是端口)
|
||||
|
||||
```
|
||||
Listen 127.0.0.1:80
|
||||
|
||||
```
|
||||
|
||||
通过将此配置项设置为`localhost`的 IP 地址,Apache 将只侦听来自本地主机的连接。 如果您希望 Web 服务器侦听来自远程主机的连接,则可以使用主机的外部 IP 地址。
|
||||
|
||||
`DocumentRoot` 配置项指定组成网站页面的 HTML 文件的位置。 该配置项不需要更改,因为它已经指向标准位置。 该行应该看起来像这样:
|
||||
|
||||
```
|
||||
DocumentRoot "/var/www/html"
|
||||
|
||||
```
|
||||
|
||||
Apache 安装包创建 `/var /www` 目录。 如果您想更改存储网站文件的位置,则使用此配置项来完成此操作。 例如,您可能想要为 `www` 子目录使用不同的名称,以更明确地识别网站。 这可能是这样的:
|
||||
|
||||
```
|
||||
DocumentRoot "/var/mywebsite/html"
|
||||
|
||||
```
|
||||
|
||||
这些是创建一个简单网站需要唯一修改的 Apache 配置项。 对于这个小练习,只对 `httpd.conf` 文件(`Listen` 配置项)进行了一些修改。 其它的配置项对于一个简单的 Web 服务器暂时无需配置。
|
||||
|
||||
另一个需要改变的地方是:在我们的防火墙中打开端口 80。 我使用 [iptables][2] 作为我的防火墙,因此我更改 `/etc/ sysconfig/iptables` 文件以添加允许使用 HTTP 协议。 整个文件看起来像这样:
|
||||
|
||||
```
|
||||
# sample configuration for iptables service
|
||||
|
||||
# you can edit this manually or use system-config-firewall
|
||||
|
||||
# please do not ask us to add additional ports/services to this default configuration
|
||||
|
||||
*filter
|
||||
|
||||
:INPUT ACCEPT [0:0]
|
||||
|
||||
:FORWARD ACCEPT [0:0]
|
||||
|
||||
:OUTPUT ACCEPT [0:0]
|
||||
|
||||
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
|
||||
|
||||
-A INPUT -p icmp -j ACCEPT
|
||||
|
||||
-A INPUT -i lo -j ACCEPT
|
||||
|
||||
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
|
||||
|
||||
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
|
||||
|
||||
-A INPUT -j REJECT --reject-with icmp-host-prohibited
|
||||
|
||||
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
|
||||
|
||||
COMMIT
|
||||
|
||||
```
|
||||
|
||||
我在文件的倒数第三行上添加了一个新行,它允许在端口 80 上输入流量。现在我重新加载 iptables 配置文件。
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# cd /etc/sysconfig/ ; iptables-restore iptables
|
||||
|
||||
```
|
||||
|
||||
### 创建 index.html 文件
|
||||
|
||||
`index.html` 文件是你使用域名访问网站而不是访问特定网页时的默认文件。在 `/var/www/html `中,创建一个名字为 `index.html` 的文件,在其中添加 `Hello World` 。你不需要添加任何的 HTML 标志去完成这项工作。web 服务器的唯一任务是提供文本数据流,服务器不知道日期是什么,也不知道如何呈现数据流。它只是将数据流传输给请求主机。
|
||||
|
||||
保存文件后,将所有权设置为 `apache.apache` 。
|
||||
|
||||
```
|
||||
[root@testvm1 html]# chown apache.apache index.html
|
||||
|
||||
```
|
||||
|
||||
### 启动 Apache
|
||||
|
||||
Apache 很容易启动。 当前版本的 Fedora 使用 `systemd` 。 运行以下命令启动它,然后检查服务器的状态:(LCTT 注:systemctl 是一个 systemd 工具)
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# systemctl start httpd
|
||||
|
||||
[root@testvm1 ~]# systemctl status httpd
|
||||
|
||||
● httpd.service - The Apache HTTP Server
|
||||
|
||||
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
|
||||
|
||||
Active: active (running) since Thu 2018-02-08 13:18:54 EST; 5s ago
|
||||
|
||||
Docs: man:httpd.service(8)
|
||||
|
||||
Main PID: 27107 (httpd)
|
||||
|
||||
Status: "Processing requests..."
|
||||
|
||||
Tasks: 213 (limit: 4915)
|
||||
|
||||
CGroup: /system.slice/httpd.service
|
||||
|
||||
├─27107 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
├─27108 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
├─27109 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
├─27110 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
└─27111 /usr/sbin/httpd -DFOREGROUND
|
||||
|
||||
|
||||
|
||||
Feb 08 13:18:54 testvm1 systemd[1]: Starting The Apache HTTP Server...
|
||||
|
||||
Feb 08 13:18:54 testvm1 systemd[1]: Started The Apache HTTP Server.
|
||||
|
||||
```
|
||||
|
||||
您的服务器上的命令可能不同。在使用 SystemV 启动脚本的Linux系统上,命令如下:
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# service httpd start
|
||||
|
||||
Starting httpd: [Fri Feb 09 08:18:07 2018] [ OK ]
|
||||
|
||||
[root@testvm1 ~]# service httpd status
|
||||
|
||||
httpd (pid 14649) is running...
|
||||
|
||||
```
|
||||
|
||||
如果您的主机上有像 Firefox 或 Chrome 这样的浏览器,您可以在浏览器的 URL 行上使用 URL `localhost` 来显示您的 web 页面,尽管它很简单。您还可以使用像 [Lynx][3] 这样的文本模式 web 浏览器来查看 web 页面。首先,安装 Lynx (如果它还没有被安装)。
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# dnf -y install lynx
|
||||
|
||||
```
|
||||
|
||||
然后使用下面的命令来显示网页。
|
||||
|
||||
```
|
||||
[root@testvm1 ~]# lynx localhost
|
||||
|
||||
```
|
||||
|
||||
结果在我的终端中是这样的。我已经删除了页面上的很多空白。
|
||||
|
||||
```
|
||||
Hello World
|
||||
|
||||
|
||||
|
||||
<snip>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Commands: Use arrow keys to move, '?' for help, 'q' to quit, '<-' to go back.
|
||||
|
||||
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
|
||||
|
||||
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list
|
||||
|
||||
```
|
||||
|
||||
接下来,编辑您的 `index.html` 文件并添加一些 HTML 标记,使其看起来像这样:
|
||||
|
||||
```
|
||||
<h1>Hello World</h1>
|
||||
|
||||
```
|
||||
|
||||
现在刷新浏览器。对于 Lynx,使用组合键 Ctrl + R 。 结果看起来有点不同。如果你的终端支持彩色的话文本是彩色显示的,Lynx 会显示标题,现在它处于居中状态。 在 GUI 浏览器中,文本将以大字体显示。
|
||||
|
||||
```
|
||||
Hello World
|
||||
|
||||
|
||||
|
||||
<snip>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Commands: Use arrow keys to move, '?' for help, 'q' to quit, '<-' to go back.
|
||||
|
||||
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
|
||||
|
||||
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list
|
||||
|
||||
```
|
||||
|
||||
### 后记
|
||||
|
||||
从这个小练习中可以看到,建立一个 Apache Web 服务器很容易。 具体情况取决于您的发行版和该发行版提供的 Apache 版本。 在我的环境中,这是一个非常简单的练习。
|
||||
|
||||
但不仅仅如此,因为 Apache 非常灵活强大。下个月,我将讨论使用单个 Apache 托管多个网站。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/2/how-configure-apache-web-server
|
||||
|
||||
作者:[David Both][a]
|
||||
译者:[amwps290](https://github.com/amwps290)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/dboth
|
||||
[1]:https://httpd.apache.org/
|
||||
[2]:https://en.wikipedia.org/wiki/Iptables
|
||||
[3]:http://lynx.browser.org/
|
Loading…
Reference in New Issue
Block a user