mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
BeliteX
GitHub
commit
09d7116f1d
@ -1,194 +0,0 @@
|
||||
【翻译中】translating by jrglinux!
|
||||
|
||||
|
||||
Start a blog in 30 minutes with Hugo, a static site generator written in Go
|
||||
======
|
||||
|
||||
|
||||
Do you want to start a blog to share your latest adventures with various software frameworks? Do you love a project that is poorly documented and want to fix that? Or do you just want to create a personal website?
|
||||
|
||||
Many people who want to start a blog have a significant caveat: lack of knowledge about a content management system (CMS) or time to learn. Well, what if I said you don't need to spend days learning a new CMS, setting up a basic website, styling it, and hardening it against attackers? What if I said you could create a blog in 30 minutes, start to finish, with [Hugo][1]?
|
||||
|
||||
|
||||
|
||||
Hugo is a static site generator written in Go. Why use Hugo, you ask?
|
||||
|
||||
* Because there is no database, no plugins requiring any permissions, and no underlying platform running on your server, there's no added security concern.
|
||||
* The blog is a set of static websites, which means lightning-fast serve time. Additionally, all pages are rendered at deploy time, so your server's load is minimal.
|
||||
* Version control is easy. Some CMS platforms use their own version control system (VCS) or integrate Git into their interface. With Hugo, all your source files can live natively on the VCS of your choice.
|
||||
|
||||
|
||||
|
||||
### Minutes 0-5: Download Hugo and generate a site
|
||||
|
||||
To put it bluntly, Hugo is here to make writing a website fun again. Let's time the 30 minutes, shall we?
|
||||
|
||||
To simplify the installation of Hugo, download the binary file. To do so:
|
||||
|
||||
1. Download the appropriate [archive][2] for your operating system.
|
||||
|
||||
2. Unzip the archive into a directory of your choice, for example `C:\hugo_dir` or `~/hugo_dir`; this path will be referred to as `${HUGO_HOME}`.
|
||||
|
||||
3. Open the command line and change into your directory: `cd ${HUGO_HOME}`.
|
||||
|
||||
4. Verify that Hugo is working:
|
||||
|
||||
* On Unix: `${HUGO_HOME}/[hugo version]`
|
||||
* On Windows: `${HUGO_HOME}\[hugo.exe version]`
|
||||
For example, `c:\hugo_dir\hugo version`.
|
||||
|
||||
For simplicity, I'll refer to the path to the Hugo binary (including the binary) as `hugo`. For example, `hugo version` would translate to `C:\hugo_dir\hugo version` on your computer.
|
||||
|
||||
If you get an error message, you may have downloaded the wrong version. Also note there are many possible ways to install Hugo. See the [official documentation][3] for more information. Ideally, you put the Hugo binary on PATH. For this quick start, it's fine to use the full path of the Hugo binary.
|
||||
|
||||
|
||||
|
||||
5. Create a new site that will become your blog: `hugo new site awesome-blog`.
|
||||
6. Change into the newly created directory: `cd awesome-blog`.
|
||||
|
||||
|
||||
|
||||
Congratulations! You have just created your new blog.
|
||||
|
||||
### Minutes 5-10: Theme your blog
|
||||
|
||||
With Hugo, you can either theme your blog yourself or use one of the beautiful, ready-made [themes][4]. I chose [Kiera][5] because it is deliciously simple. To install the theme:
|
||||
|
||||
1. Change into the themes directory: `cd themes`.
|
||||
2. Clone your theme: `git clone https://github.com/avianto/hugo-kiera kiera`. If you do not have Git installed:
|
||||
* Download the .zip file from [GitHub][5].
|
||||
* Unzip it to your site's `themes` directory.
|
||||
* Rename the directory from `hugo-kiera-master` to `kiera`.
|
||||
3. Change the directory to the awesome-blog level: `cd awesome-blog`.
|
||||
4. Activate the theme. Themes (including Kiera) often come with a directory called `exampleSite`, which contains example content and an example settings file. To activate Kiera, copy the provided `config.toml` file to your blog:
|
||||
* On Unix: `cp themes/kiera/exampleSite/config.toml .`
|
||||
* On Windows: `copy themes\kiera\exampleSite\config.toml .`
|
||||
* Confirm `Yes` to override the old `config.toml`
|
||||
5. (Optional) You can start your server to visually verify the theme is activated: `hugo server -D` and access `http://localhost:1313` in your web browser. Once you've reviewed your blog, you can turn off the server by pressing `Ctrl+C` in the command line. Your blog is empty, but we're getting someplace. It should look something like this:
|
||||
|
||||
|
||||
|
||||
You have just themed your blog! You can find hundreds of beautiful themes on the official [Hugo themes][4] site.
|
||||
|
||||
### Minutes 10-20: Add content to your blog
|
||||
|
||||
Whereas a bowl is most useful when it is empty, this is not the case for a blog. In this step, you'll add content to your blog. Hugo and the Kiera theme simplify this process. To add your first post:
|
||||
|
||||
1. Article archetypes are templates for your content.
|
||||
2. Add theme archetypes to your blog site:
|
||||
* On Unix: `cp themes/kiera/archetypes/* archetypes/`
|
||||
* On Windows: `copy themes\kiera\archetypes\* archetypes\`
|
||||
* Confirm `Yes` to override the `default.md` archetype
|
||||
3. Create a new directory for your blog posts:
|
||||
* On Unix: `mkdir content/posts`
|
||||
* On Windows: `mkdir content\posts`
|
||||
4. Use Hugo to generate your post:
|
||||
* On Unix: `hugo new posts/first-post.md`
|
||||
* On Windows: `hugo new posts\first-post.md`
|
||||
5. Open the new post in a text editor of your choice:
|
||||
* On Unix: `gedit content/posts/first-post.md`
|
||||
* On Windows: `notepad content\posts\first-post.md`
|
||||
|
||||
|
||||
|
||||
At this point, you can go wild. Notice that your post consists of two sections. The first one is separated by `+++`. It contains metadata about your post, such as its title. In Hugo, this is called front matter. After the front matter, the article begins. Create the first post:
|
||||
```
|
||||
+++
|
||||
|
||||
title = "First Post"
|
||||
|
||||
date = 2018-03-03T13:23:10+01:00
|
||||
|
||||
draft = false
|
||||
|
||||
tags = ["Getting started"]
|
||||
|
||||
categories = []
|
||||
|
||||
+++
|
||||
|
||||
|
||||
|
||||
Hello Hugo world! No more excuses for having no blog or documentation now!
|
||||
|
||||
```
|
||||
|
||||
All you need to do now is start the server: `hugo server -D`. Open your browser and enter: `http://localhost:1313/`.
|
||||
|
||||
|
||||
### Minutes 20-30: Tweak your site
|
||||
|
||||
What we've done is great, but there are still a few niggles to iron out. For example, naming your site is simple:
|
||||
|
||||
1. Stop your server by pressing `Ctrl+C` on the command line.
|
||||
2. Open `config.toml` and edit settings such as the blog's title, copyright, name, your social network links, etc.
|
||||
|
||||
|
||||
|
||||
When you start your server again, you'll see your blog has a bit more personalization. One more basic thing is missing: menus. That's a quick fix as well. Back in `config.toml`, insert the following at the bottom:
|
||||
```
|
||||
[[menu.main]]
|
||||
|
||||
name = "Home" #Name in the navigation bar
|
||||
|
||||
weight = 10 #The larger the weight, the more on the right this item will be
|
||||
|
||||
url = "/" #URL address
|
||||
|
||||
[[menu.main]]
|
||||
|
||||
name = "Posts"
|
||||
|
||||
weight = 20
|
||||
|
||||
url = "/posts/"
|
||||
|
||||
```
|
||||
|
||||
This adds menus for Home and Posts. You still need an About page. Instead of referencing it from the `config.toml` file, reference it from a markdown file:
|
||||
|
||||
1. Create an About file: `hugo new about.md`. Notice that it's `about.md`, not `posts/about.md`. The About page is not a blog post, so you don't want it displayed in the Posts section.
|
||||
2. Open the file in a text editor and enter the following:
|
||||
|
||||
|
||||
```
|
||||
+++
|
||||
|
||||
title = "About"
|
||||
|
||||
date = 2018-03-03T13:50:49+01:00
|
||||
|
||||
menu = "main" #Display this page on the nav menu
|
||||
|
||||
weight = "30" #Right-most nav item
|
||||
|
||||
meta = "false" #Do not display tags or categories
|
||||
|
||||
+++
|
||||
|
||||
|
||||
|
||||
> Waves are the practice of the water. Shunryu Suzuki
|
||||
|
||||
```
|
||||
|
||||
When you start your Hugo server and open `http://localhost:1313/`, you should see your new blog ready to be used. (Check out [my example][6] on my GitHub page.) If you'd like to change the active style of menu items to make the padding slightly nicer (like the GitHub live version), apply [this patch][7] to your `themes/kiera/static/css/styles.css` file.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/start-blog-30-minutes-hugo
|
||||
|
||||
作者：[Marek Czernek][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/mczernek
|
||||
[1]:https://gohugo.io/
|
||||
[2]:https://github.com/gohugoio/hugo/releases
|
||||
[3]:https://gohugo.io/getting-started/installing/
|
||||
[4]:https://themes.gohugo.io/
|
||||
[5]:https://github.com/avianto/hugo-kiera
|
||||
[6]:https://m-czernek.github.io/awesome-blog/
|
||||
[7]:https://github.com/avianto/hugo-kiera/pull/18/files
|
||||
@ -1,226 +0,0 @@
|
||||
LuMing translating
|
||||
How To Configure SSH Key-based Authentication In Linux
|
||||
======
|
||||
|
||||
|
||||
|
||||
### What is SSH Key-based authentication?
|
||||
|
||||
As we all know, **Secure Shell** , shortly **SSH** , is the cryptographic network protocol that allows you to securely communicate/access a remote system over unsecured network, for example Internet. Whenever you send a data over an unsecured network using SSH, the data will be automatically encrypted in the source system, and decrypted in the destination side. SSH provides four authentication methods namely **password-based authentication** , **key-based authentication** , **Host-based authentication** , and **Keyboard authentication**. The most commonly used authentication methods are password-based and key-based authentication.
|
||||
|
||||
In password-based authentication, all you need is the password of the remote system’s user. If you know the password of remote user, you can access the respective system using **“ssh[[email protected]][1]”**. On the other hand, in key-based authentication, you need to generate SSH key pairs and upload the SSH public key to the remote system in order to communicate it via SSH. Each SSH key pair consists of a private key and public key. The private key should be kept within the client system, and the public key should uploaded to the remote systems. You shouldn’t disclose the private key to anyone. Hope you got the basic idea about SSH and its authentication methods.
|
||||
|
||||
In this tutorial, we will be discussing how to configure SSH key-based authentication in Linux.
|
||||
|
||||
### Configure SSH Key-based Authentication In Linux
|
||||
|
||||
For the purpose of this guide, I will be using Arch Linux system as local system and Ubuntu 18.04 LTS as remote system.
|
||||
|
||||
Local system details:
|
||||
|
||||
* **OS** : Arch Linux Desktop
|
||||
* **IP address** : 192.168.225.37 /24
|
||||
|
||||
|
||||
|
||||
Remote system details:
|
||||
|
||||
* **OS** : Ubuntu 18.04 LTS Server
|
||||
* **IP address** : 192.168.225.22/24
|
||||
|
||||
|
||||
|
||||
### Local system configuration
|
||||
|
||||
Like I said already, in SSH key-based authentication method, the public key should be uploaded to the remote system that you want to access via SSH. The public keys will usually be stored in a file called **~/.ssh/authorized_keys** in the remote SSH systems.
|
||||
|
||||
**Important note:** Do not generate key pairs as **root** , as only root would be able to use those keys. Create key pairs as normal user.
|
||||
|
||||
Now, let us create the SSH key pair in the local system. To do so, run the following command in your client system.
|
||||
```
|
||||
$ ssh-keygen
|
||||
|
||||
```
|
||||
|
||||
The above command will create 2048 bit RSA key pair. Enter the passphrase twice. More importantly, Remember your passphrase. You’ll need it later.
|
||||
|
||||
**Sample output:**
|
||||
```
|
||||
Generating public/private rsa key pair.
|
||||
Enter file in which to save the key (/home/sk/.ssh/id_rsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /home/sk/.ssh/id_rsa.
|
||||
Your public key has been saved in /home/sk/.ssh/id_rsa.pub.
|
||||
The key fingerprint is:
|
||||
SHA256:wYOgvdkBgMFydTMCUI3qZaUxvjs+p2287Tn4uaZ5KyE [email protected]
|
||||
The key's randomart image is:
|
||||
+---[RSA 2048]----+
|
||||
|+=+*= + |
|
||||
|o.o=.* = |
|
||||
|.oo * o + |
|
||||
|. = + . o |
|
||||
|. o + . S |
|
||||
| . E . |
|
||||
| + o |
|
||||
| +.*o+o |
|
||||
| .o*=OO+ |
|
||||
+----[SHA256]-----+
|
||||
|
||||
```
|
||||
|
||||
In case you have already created the key pair, you will see the following message. Just type “y” to create overwrite the existing key .
|
||||
```
|
||||
/home/username/.ssh/id_rsa already exists.
|
||||
Overwrite (y/n)?
|
||||
|
||||
```
|
||||
|
||||
Please note that **passphrase is optional**. If you give one, you’ll be asked to enter the password every time when you try to SSH a remote system unless you are using any SSH agent to store the password. If you don’t want passphrase(not safe though), simply press ENTER key twice when you’ll be asked to enter the passphrase. However, we recommend you to use passphrase. Using a password-less ssh key is generally not a good idea from a security point of view. They should be limited to very specific cases such as services having to access a remote system without the user intervention (e.g. remote backups with rsync, …).
|
||||
|
||||
If you already have a ssh key without a passphrase in private file **~/.ssh/id_rsa** and wanted to update key with passphrase, use the following command:
|
||||
```
|
||||
$ ssh-keygen -p -f ~/.ssh/id_rsa
|
||||
|
||||
```
|
||||
|
||||
Sample output:
|
||||
```
|
||||
Enter new passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved with the new passphrase.
|
||||
|
||||
```
|
||||
|
||||
Now, we have created the key pair in the local system. Now, copy the SSH public key to your remote SSH server using command:
|
||||
|
||||
Here, I will be copying the local (Arch Linux) system’s public key to the remote system (Ubuntu 18.04 LTS in my case). Technically speaking, the above command will copy the contents of local system’s **~/.ssh/id_rsa.pub key** into remote system’s **~/.ssh/authorized_keys** file. Clear? Good.
|
||||
|
||||
Type **yes** to continue connecting to your remote SSH server. And, then Enter the root user’s password of the remote system.
|
||||
```
|
||||
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
|
||||
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
|
||||
[email protected]2.168.225.22's password:
|
||||
|
||||
Number of key(s) added: 1
|
||||
|
||||
Now try logging into the machine, with: "ssh '[email protected]'"
|
||||
and check to make sure that only the key(s) you wanted were added.
|
||||
|
||||
```
|
||||
|
||||
If you have already copied the key, but want to update the key with new passphrase, use **-f** option to overwrite the existing key like below.
|
||||
|
||||
We have now successfully added the local system’s SSH public key to the remote system. Now, let us disable the password-based authentication completely in the remote system. Because, we have configured key-based authentication, so we don’t need password-base authentication anymore.
|
||||
|
||||
### Disable SSH Password-based authentication in remote system
|
||||
|
||||
You need to perform the following commands as root or sudo user.
|
||||
|
||||
To disable password-based authentication, go to your remote system’s console and edit **/etc/ssh/sshd_config** configuration file using any editor:
|
||||
```
|
||||
$ sudo vi /etc/ssh/sshd_config
|
||||
|
||||
```
|
||||
|
||||
Find the following line. Uncomment it and set it’s value as **no**.
|
||||
```
|
||||
PasswordAuthentication no
|
||||
|
||||
```
|
||||
|
||||
Restart ssh service to take effect the changes.
|
||||
```
|
||||
$ sudo systemctl restart sshd
|
||||
|
||||
```
|
||||
|
||||
### Access Remote system from local system
|
||||
|
||||
Go to your local system and SSH into your remote server using command:
|
||||
|
||||
Enter the passphrase.
|
||||
|
||||
**Sample output:**
|
||||
```
|
||||
Enter passphrase for key '/home/sk/.ssh/id_rsa':
|
||||
Last login: Mon Jul 9 09:59:51 2018 from 192.168.225.37
|
||||
[email protected]:~$
|
||||
|
||||
```
|
||||
|
||||
Now, you’ll be able to SSH into your remote system. As you noticed, we have logged-in to the remote system’s account using passphrase which we created earlier using **ssh-keygen** command, not using the actual account’s password.
|
||||
|
||||
If you try to ssh from another client system, you will get this error message. Say for example, I am tried to SSH into my Ubuntu system from my CentOS using command:
|
||||
|
||||
**Sample output:**
|
||||
```
|
||||
The authenticity of host '192.168.225.22 (192.168.225.22)' can't be established.
|
||||
ECDSA key fingerprint is 67:fc:69:b7:d4:4d:fd:6e:38:44:a8:2f:08:ed:f4:21.
|
||||
Are you sure you want to continue connecting (yes/no)? yes
|
||||
Warning: Permanently added '192.168.225.22' (ECDSA) to the list of known hosts.
|
||||
Permission denied (publickey).
|
||||
|
||||
```
|
||||
|
||||
As you see in the above output, I can’t SSH into my remote Ubuntu 18.04 systems from any other systems, except the CentOS system.
|
||||
|
||||
### Adding more Client system’s keys to SSH server
|
||||
|
||||
This is very important. Like I said already, you can’t access the remote system via SSH, except the one you configured (In our case, it’s Ubuntu). I want to give permissions to more clients to access the remote SSH server. What should I do? Simple. You need to generate the SSH key pair in all your client systems and copy the ssh public key manually to the remote server that you want to access via SSH.
|
||||
|
||||
To create SSH key pair on your client system’s, run:
|
||||
```
|
||||
$ ssh-keygen
|
||||
|
||||
```
|
||||
|
||||
Enter the passphrase twice. Now, the ssh key pair is generated. You need to copy the public ssh key (not private key) to your remote server manually.
|
||||
|
||||
Display the pub key using command:
|
||||
```
|
||||
$ cat ~/.ssh/id_rsa.pub
|
||||
|
||||
```
|
||||
|
||||
You should an output something like below.
|
||||
|
||||
Copy the entire contents (via USB drive or any medium) and go to your remote server’s console. Create a directory called **ssh** in the home directory as shown below. You need to execute the following commands as root user.
|
||||
```
|
||||
$ mkdir -p ~/.ssh
|
||||
|
||||
```
|
||||
|
||||
Now, append the your client system’s pub key which you generated in the previous step in a file called
|
||||
```
|
||||
echo {Your_public_key_contents_here} >> ~/.ssh/authorized_keys
|
||||
|
||||
```
|
||||
|
||||
Restart ssh service on the remote system. Now, you’ll be able to SSH to your server from the new client.
|
||||
|
||||
If manually adding ssh pubkey seems difficult, enable password-based authentication temporarily in the remote system and copy the key using “ssh-copy-id” command from your local system and finally disable the password-based authentication.
|
||||
|
||||
**Suggested read:**
|
||||
|
||||
And, that’s all for now. SSH Key-based authentication provides an extra layer protection from brute-force attacks. As you can see, configuring key-based authentication is not that difficult either. It is one of the recommended method to keep your Linux servers safe and secure.
|
||||
|
||||
I will be here soon with another useful article. Until then, stay tuned with OSTechNix.
|
||||
|
||||
Cheers!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/configure-ssh-key-based-authentication-linux/
|
||||
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.ostechnix.com/author/sk/
|
||||
[1]:https://www.ostechnix.com/cdn-cgi/l/email-protection
|
||||
@ -1,75 +0,0 @@
|
||||
[translating by jamelouis]
|
||||
Getting started with openmediavault: A home NAS solution
|
||||
======
|
||||
This network-attached file server offers a solid array of features and is easy to install and configure.
|
||||
|
||||
|
||||
|
||||
With so many cloud storage options readily available, some folks might question the value of having a home NAS (network-attached storage) server. After all, with your files on the cloud, you don't have to worry about managing the maintenance, updates, and security of your own server.
|
||||
|
||||
But that's not entirely true, is it? You have a home network, so you've got to pay at least some attention to that network's health and security. Assuming you're already keeping on top of that, then [a home NAS][1] really isn't adding that much additional hassle. And there are all kinds of benefits to gain from that minor amount of work.
|
||||
|
||||
You can have a local backup of every computer in your house (you can also back up off-site). Have a media server that holds movies, music, and photos regardless of whether your internet connection flakes out. Work on large files on multiple computers in your home without waiting for them to traverse from some random computer somewhere else on the internet. Plus, you can have your NAS pull double duty with other services, like hosting local email or a household wiki. Perhaps most importantly, with a home NAS, your data is your data—under your control and always accessible.
|
||||
|
||||
The follow-on question is which NAS solution to choose. Sure, you could buy a pre-built solution and call it a day, but what fun is that? And practically speaking, although it's great to have an appliance that handles everything for you, it's often better to have a rig that you can fix and upgrade yourself. This is the situation I found myself in recently. I chose to install and set up [openmediavault][2].
|
||||
|
||||
### Why openmediavault?
|
||||
|
||||
There are a few open source NAS solutions out there, some arguably more popular than openmediavault. When I asked around, for instance, [FreeNAS][3] was recommended the most. So why didn't I go with that? After all, it is more widely used, includes more features, and offers more support options, [according to a comparison on the FreeNAS website][4]. That's certainly all true. But openmediavault is no slouch. It's actually based on an earlier version of FreeNAS, and while its numbers are lower in terms of downloads and features, they're more than adequate for my needs.
|
||||
|
||||
Another factor was a simple matter of comfort. Openmediavault's underlying operating system is [Debian][5], whereas FreeNAS sits atop [FreeBSD][6]. I'm personally not as familiar with FreeBSD, so that would make it more difficult for me to fix things if my NAS starts misbehaving. It also makes it more difficult for me to tweak things or add my own services to the machine if I want. Sure, I could learn FreeBSD and get more familiar with it, but I'm already home-building this NAS; I've found that projects tend to be more successful if you limit the number of "learning opportunities" you give yourself to complete them.
|
||||
|
||||
Every situation is different, of course, so do your research and decide what seems to be the best fit for you. FreeNAS looks like the right solution for a lot of people. Openmediavault was the right one for me.
|
||||
|
||||
### Installation and configuration
|
||||
|
||||
The installation process is pretty well covered in the [openmediavault documentation][7], so I won't rehash that here. If you've ever installed a Linux distribution, most of the steps should look familiar to you (though with a somewhat uglier [Ncurses][8] interface than you might see on modern distributions). I installed it using the [dedicated drive][9] instructions. However, those instructions, while good, are rather spartan. When you're done, you have a base system installed, but there's more to do before you can actually use your NAS to store any files. For instance, the dedicated drive instructions install openmediavault on a hard drive, but that's the operating system drive, not the one with the shared space that's accessible to other computers on your network. You need to walk yourself through setting that up and configuring it.
|
||||
|
||||
The first thing you should do is load up the administrative web interface and change the default password. This password is different from the root password you set during the installation process. It's the administrative account for the web interface, and the default username and password are `admin` and `openmediavault`, respectively—definitely something you'll want to change immediately after logging in.
|
||||
|
||||
#### Set up your drives
|
||||
|
||||
Once you've installed openmediavault, you need it to actually do stuff for you. The first logical step is to set up the drives that you're going to use for storage. I'm assuming that you've already got them physically installed, so all you have to do at this point is get openmediavault to recognize them and configure them. The first step is making sure those disks are visible. The sidebar menu has a lot of options, but it's very sensibly organized. Go to **Storage - > Disks**. Once you click that, you should see all of the drives you've installed on your server, including the one where you actually installed openmediavault. If you don't see all of your drives there, click the Scan button to see if it picks them up. Usually, it's not a problem.
|
||||
|
||||
You could mount these drives individually to set them up as your file share, but for a file server, you'll want some redundancy. You want to be able to treat multiple drives as a single volume and recover your data if a drive fails or add new drives when you start running out of space. That means you're going to want a [RAID][10]. The topic of what specific type of RAID configuration you want is a deep rabbit hole that deserves an article all of its own (and many have been written), but suffice it to say that you'll need more than one drive, and in the best case, all of your drives store the same amount of data.
|
||||
|
||||
Openmediavault supports all standard RAID levels, so you're good to go there. Configure your RAID in **Storage - > RAID Management**. Configuration is absurdly simple: Click the Create button, choose the disks you want in your RAID array, the RAID level you want to use, and a name for the array. Openmediavault handles the rest for you. There's no messing around at the command line, trying to remember which flags to use with the `mdadm` command. In my specific case, I have six 2-TB drives that I've set up as RAID 10.
|
||||
|
||||
With your RAID set up, you've almost got a place to store things. You just need to set up a file system. Just like your desktop computer, a hard drive doesn't do you any good until you format it. So the next place to go in openmediavault's control panel is **Storage - > File Systems**. Just like configuring your RAID, click the Create button and follow the prompts. In this case, you choose the device to format. If you have only the one RAID on your server, it should be something like `md0`. You'll also need to choose the filesystem type. If you're not sure, just use the standard ext4 type.
|
||||
|
||||
#### Define your shares
|
||||
|
||||
Sweet! You've got a place to store files. Now you just need to make it visible on your home network. Configure this from the **Services** section of the openmediavault control panel. When it comes to setting up a file share on a network, there are really two main choices: NFS or SMB/CIFS. As a rule of thumb, if all of the computers on your network are running Linux distributions, then you're probably better off using NFS. However, if your home network is a mixed environment with a combination of Linux, Windows, Mac OS, and embedded devices, then SMB/CIFS is probably the right choice.
|
||||
|
||||
These options aren't mutually exclusive. You could actually run both services on your server and get the best of both worlds. Or you could mix it up if you have specific devices dedicated to particular tasks. Whatever your usage scenario, configuring these services is dirt simple. Click on the service you want, enable it from its Settings, and define the shared folders you want visible on the network. In the case of SMB/CIFS shares, there are a few more settings available than with NFS, but most of the defaults are fine to start with. The cool thing is that since it's so easy to configure, it's also pretty easy to change on the fly.
|
||||
|
||||
#### Configure users
|
||||
|
||||
You're almost done. You've configured your drives in a RAID. You've formatted that RAID with a file system. And you've defined shared folders on that formatted RAID. The only thing left is saying who can access those shares and how much. This is handled from the **Access Rights Management** section. Use the **User** and **Group** sections to define the users who connect to your shared folders and the permissions they have with the files in those folders.
|
||||
|
||||
Once you do that, you're pretty much good to go. You'll need to access your shares from your various client machines, but that's a topic for another article.
|
||||
|
||||
Have fun!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/9/openmediavault
|
||||
|
||||
作者：[Jason van Gumster][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者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/mairin
|
||||
[1]: https://opensource.com/article/18/8/automate-backups-raspberry-pi
|
||||
[2]: https://openmediavault.org
|
||||
[3]: https://freenas.org
|
||||
[4]: http://www.freenas.org/freenas-vs-openmediavault/
|
||||
[5]: https://www.debian.org/
|
||||
[6]: https://www.freebsd.org/
|
||||
[7]: https://openmediavault.readthedocs.io/en/latest/installation/index.html
|
||||
[8]: https://invisible-island.net/ncurses/
|
||||
[9]: https://openmediavault.readthedocs.io/en/latest/installation/via_iso.html
|
||||
[10]: https://en.wikipedia.org/wiki/RAID
|
||||
@ -0,0 +1,179 @@
|
||||
Hugo，30分钟搭建博客，一个Go语言开发的静态站点生成工具
|
||||
======
|
||||
|
||||
|
||||
你是不是强烈的想搭建博客来将自己对软件框架等的探索学习成果分享呢？
|
||||
|
||||
你是不是面对缺乏指导文档而一团糟的项目就有一种想去改变它的冲动呢？
|
||||
|
||||
或者换个角度，你是不是十分期待能创建一个属于自己的个人博客网站呢？
|
||||
|
||||
很多人在想搭建博客之前都有一些严重的迟疑顾虑：感觉自己缺乏内容管理系统（CMS）的相关知识，更缺乏时间去学习这些知识。现在，如果我说不用花费大把的时间去学习 CMS 系统、学习如何创建一个静态网站、更不用操心如何去强化网站以防止它受到黑客攻击的问题，你就可以在 30 分钟之内创建一个博客？你信不信？利用 Hugo 工具，就可以实现这一切。
|
||||
|
||||
|
||||
|
||||
Hugo 是一个基于 Go 语言开发的静态站点生成工具。也许你会问，为什么选择它？
|
||||
* 无需数据库、无需需要各种权限的插件、无需跑在服务器上的底层平台，更没有额外的安全问题。
|
||||
* 都是静态站点，因此拥有轻量级、快速响应的服务性能。此外，所有的网页都是在部署的时候呈现，所以服务器负载很小。
|
||||
* 极易操作的版本控制。一些 CMS 平台使用它们自己的版本控制软件（VCS）或者在网页上集成 Git 工具。而 Hugo，所有的源文件都可以用你所选的 VCS 软件来管理。
|
||||
|
||||
### 0-5 分钟：下载 Hugo，生成一个网站
|
||||
|
||||
直白的说，Hugo 使得写一个网站又一次变得有趣起来。让我们来个 30 分钟计时，搭建一个网站。
|
||||
|
||||
为了简化 Hugo 安装流程，这里直接使用 Hugo 可执行安装文件。
|
||||
|
||||
1. 下载和你操作系统匹配的 Hugo [版本][2]；
|
||||
|
||||
2. 压缩包解压到指定路径，例如 windows 系统的 `C:\hugo_dir` 或者 Linux 系统的 `~/hugo_dir` 目录；下文中的变量 `${HUGO_HOME}` 所指的路径就是这个安装目录；
|
||||
|
||||
3. 打开命令行终端，进入安装目录：`cd ${HUGO_HOME}`；
|
||||
|
||||
4. 确认 Hugo 已经启动：
|
||||
* Unix 系统：`${HUGO_HOME}/[hugo version]`；
|
||||
* Windows 系统：`${HUGO_HOME}\[hugo.exe version]`；
|
||||
|
||||
例如：Windows 系统下，cmd 命令行中输入：`c:\hugo_dir\hugo version`。
|
||||
|
||||
为了书写上的简化，下文中的 `hugo` 就是指 hugo 可执行文件所在的路径（包括可执行文件），例如命令 `hugo version` 就是指命令 `c:\hugo_dir\hugo version` 。(译者注：可以把 hugo 可执行文件所在的路径添加到系统环境变量下，这样就可以直接在终端中输入 `hugo version`）
|
||||
如果命令 `hugo version` 报错，你可能下载了错误的版本。当然，有很多种方法安装 Hugo，更多详细信息请查阅 [官方文档][3]。最稳妥的方法就是把 Hugo 可执行文件放在某个路径下，然后执行的时候带上路径名
|
||||
|
||||
5. 创建一个新的站点来作为你的博客，输入命令：`hugo new site awesome-blog`；
|
||||
|
||||
6. 进入新创建的路径下: `cd awesome-blog`；
|
||||
|
||||
恭喜你！你已经创建了自己的新博客。
|
||||
|
||||
### 5-10 分钟：为博客设置主题
|
||||
|
||||
Hugo 中你可以自己构建博客的主题或者使用网上已经有的一些主题。这里选择 [Kiera][4] 主题，因为它简洁漂亮。按以下步骤来安装该主题：
|
||||
|
||||
1. 进入主题所在目录：`cd themes`；
|
||||
|
||||
2. 克隆主题：`git clone https://github.com/avianto/hugo-kiera kiera`。如果你没有安装 Git 工具：
|
||||
* 从 [Github][5] 上下载 hugo 的 .zip 格式的文件；
|
||||
* 解压该 .zip 文件到你的博客主题 `theme` 路径；
|
||||
* 重命名 `hugo-kiera-master` 为 `kiera`；
|
||||
|
||||
3. 返回博客主路径：`cd awesome-blog`；
|
||||
|
||||
4. 激活主题；通常来说，主题（包括 Kiera ）都自带文件夹 `exampleSite`，里面存放了内容配置的示例文件。激活 Kiera 主题需要拷贝它提供的 `config.toml` 到你的博客下：
|
||||
* Unix 系统：`cp themes/kiera/exampleSite/config.toml .`；
|
||||
* Windows 系统：`copy themes\kiera\exampleSite\config.toml .`；
|
||||
* 选择 `Yes` 来覆盖原有的 `config.toml`；
|
||||
|
||||
5. （ 可选操作 ）你可以选择可视化的方式启动服务器来验证主题是否生效：`hugo server -D` 然后在浏览器中输入 `http://localhost:1313`。可用通过在终端中输入 `Crtl+C` 来停止服务器运行。现在你的博客还是空的，但这也给你留了写作的空间。它看起来如下所示：
|
||||
|
||||
|
||||
|
||||
你已经成功的给博客设置了主题！你可以在官方 [Hugo 主题][4] 网站上找到上百种漂亮的主题供你使用。
|
||||
|
||||
### 10-20 分钟：给博客添加内容
|
||||
|
||||
对于碗来说，它是空的时候用处最大，可以用来盛放东西；但对于博客来说不是这样，空博客几乎毫无用处。在这一步，你将会给博客添加内容。Hugo 和 Kiera 主题都为这个工作提供了方便性。按以下步骤来进行你的第一次提交：
|
||||
|
||||
1. archetypes 将会是你的内容模板。
|
||||
|
||||
2. 添加主题中的 archtypes 至你的博客：
|
||||
* Unix 系统： `cp themes/kiera/archetypes/* archetypes/`
|
||||
* Windows 系统：`copy themes\kiera\archetypes\* archetypes\`
|
||||
* 选择 `Yes` 来覆盖原来的 `default.md` 内容架构类型
|
||||
|
||||
3. 创建博客 posts 目录：
|
||||
* Unix 系统： `mkdir content/posts`
|
||||
* Windows 系统： `mkdir content\posts`
|
||||
|
||||
4. 利用 Hugo 生成你的 post：
|
||||
* Unix 系统：`hugo nes posts/first-post.md`;
|
||||
* Windows 系统：`hugo new posts\first-post.md`;
|
||||
|
||||
5. 在文本编辑器中打开这个新建的 post 文件：
|
||||
* Unix 系统：`gedit content/posts/first-post.md`；
|
||||
* Windows 系统：`notepadd content\posts\first-post.md`；
|
||||
|
||||
此刻，你可以疯狂起来了。注意到你的提交文件中包括两个部分。第一部分是以 `+++` 符号分隔开的。它包括了提交文档的主要数据，例如名称、时间等。在 Hugo 中，这叫做前缀。在前缀之后，才是正文。下面编辑第一个提交文件内容：
|
||||
|
||||
```
|
||||
+++
|
||||
title = "First Post"
|
||||
date = 2018-03-03T13:23:10+01:00
|
||||
draft = false
|
||||
tags = ["Getting started"]
|
||||
categories = []
|
||||
+++
|
||||
Hello Hugo world! No more excuses for having no blog or documentation now!
|
||||
```
|
||||
|
||||
现在你要做的就是启动你的服务器：`hugo server -D`；然后打开浏览器，输入 `http://localhost:1313/`。
|
||||
|
||||
|
||||
|
||||
### 20-30 分钟：调整网站
|
||||
|
||||
前面的工作很完美，但还有一些问题需要解决。例如，简单地命名你的站点：
|
||||
|
||||
1. 终端中按下 `Ctrl+C` 以停止服务器。
|
||||
|
||||
2. 打开 `config.toml`,编辑博客的名称，版权，你的姓名，社交网站等等。
|
||||
|
||||
当你再次启动服务器后，你会发现博客私人订制味道更浓了。不过，还少一个重要的基础内容：主菜单。快速的解决这个问题。返回 `config.toml` 文件，在末尾插入如下一段：
|
||||
|
||||
```
|
||||
[[menu.main]]
|
||||
name = "Home" #Name in the navigation bar
|
||||
weight = 10 #The larger the weight, the more on the right this item will be
|
||||
url = "/" #URL address
|
||||
[[menu.main]]
|
||||
name = "Posts"
|
||||
weight = 20
|
||||
url = "/posts/"
|
||||
```
|
||||
|
||||
上面这段代码添加了 `Home` 和 `Posts` 到主菜单中。你还需要一个 `About` 页面。这次是创建一个 `.md` 文件，而不是编辑 `config.toml` 文件：
|
||||
|
||||
1. 创建 `about.md` 文件：`hugo new about.md` 。注意它是 `about.md`，不是 `posts/about.md`。该页面不是博客提交内容，所以你不想它显示到博客内容提交当中吧。
|
||||
|
||||
2. 用文本编辑器打开该文件，输入如下一段：
|
||||
|
||||
```
|
||||
+++
|
||||
title = "About"
|
||||
date = 2018-03-03T13:50:49+01:00
|
||||
menu = "main" #Display this page on the nav menu
|
||||
weight = "30" #Right-most nav item
|
||||
meta = "false" #Do not display tags or categories
|
||||
+++
|
||||
> Waves are the practice of the water. Shunryu Suzuki
|
||||
|
||||
```
|
||||
|
||||
当你启动你的服务器并输入：`http://localhost:1313/`，你将会看到你的博客。（访问我 Gihub 主页上的 [例子][6] ）如果你想让文章的菜单栏和 Github 相似，给 `themes/kiera/static/css/styles.css` 打上这个 [补丁][7]。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/start-blog-30-minutes-hugo
|
||||
|
||||
作者：[Marek Czernek][a]
|
||||
|
||||
译者：[jrg](https://github.com/jrglinux)
|
||||
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/mczernek
|
||||
|
||||
[1]:https://gohugo.io/
|
||||
|
||||
[2]:https://github.com/gohugoio/hugo/releases
|
||||
|
||||
[3]:https://gohugo.io/getting-started/installing/
|
||||
|
||||
[4]:https://themes.gohugo.io/
|
||||
|
||||
[5]:https://github.com/avianto/hugo-kiera
|
||||
|
||||
[6]:https://m-czernek.github.io/awesome-blog/
|
||||
|
||||
[7]:https://github.com/avianto/hugo-kiera/pull/18/files
|
||||
@ -0,0 +1,235 @@
|
||||
如何在 Linux 中配置基于密钥认证的 SSH
|
||||
======
|
||||
|
||||
|
||||
|
||||
### 什么是基于 SSH密钥的认证？
|
||||
|
||||
众所周知，**Secure Shell**，又称 **SSH**，是允许你通过无安全网络(例如 Internet)和远程系统之间安全访问/通信的加密网络协议。无论何时使用 SSH 在无安全网络上发送数据，它都会在源系统上自动地被加密，并且在目的系统上解密。SSH 提供了四种加密方式，**基于密码认证**，**基于密钥认证**，**基于主机认证**和**键盘认证**。最常用的认证方式是基于密码认证和基于密钥认证。
|
||||
|
||||
在基于密码认证中，你需要的仅仅是远程系统上用户的密码。如果你知道远程用户的密码，你可以使用**“ssh[[email protected]][1]”**访问各自的系统。另一方面，在基于密钥认证中，为了通过 SSH 通信，你需要生成 SSH 密钥对，并且为远程系统上传 SSH 公钥。每个 SSH 密钥对由私钥与公钥组成。私钥应该保存在客户系统上，公钥应该上传给远程系统。你不应该将私钥透露给任何人。希望你已经对 SSH 和它的认证方式有了基本的概念。
|
||||
|
||||
这篇教程，我们将讨论如何在 linux 上配置基于密钥认证的 SSH。
|
||||
|
||||
### 在 Linux 上配置基于密钥认证的SSH
|
||||
|
||||
为本篇教程起见，我将使用 Arch Linux 为本地系统，Ubuntu 18.04 LTS 为远程系统。
|
||||
|
||||
本地系统详情：
|
||||
* **OS** : Arch Linux Desktop
|
||||
* **IP address** : 192.168.225.37 /24
|
||||
|
||||
远程系统详情：
|
||||
* **OS** : Ubuntu 18.04 LTS Server
|
||||
* **IP address** : 192.168.225.22/24
|
||||
|
||||
### 本地系统配置
|
||||
|
||||
就像我之前所说，在基于密钥认证的方法中，想要通过 SSH 访问远程系统，就应该将公钥上传给它。公钥通常会被保存在远程系统的一个文件**~/.ssh/authorized_keys** 中。
|
||||
|
||||
**注意事项：**不要使用**root** 用户生成密钥对，这样只有 root 用户才可以使用。使用普通用户创建密钥对。
|
||||
|
||||
现在，让我们在本地系统上创建一个 SSH 密钥对。只需要在客户端系统上运行下面的命令。
|
||||
|
||||
```
|
||||
$ ssh-keygen
|
||||
```
|
||||
|
||||
上面的命令将会创建一个 2048 位的 RSA 密钥对。输入两次密码。更重要的是，记住你的密码。后面将会用到它。
|
||||
|
||||
**样例输出**
|
||||
|
||||
```
|
||||
Generating public/private rsa key pair.
|
||||
Enter file in which to save the key (/home/sk/.ssh/id_rsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /home/sk/.ssh/id_rsa.
|
||||
Your public key has been saved in /home/sk/.ssh/id_rsa.pub.
|
||||
The key fingerprint is:
|
||||
SHA256:wYOgvdkBgMFydTMCUI3qZaUxvjs+p2287Tn4uaZ5KyE [email protected]
|
||||
The key's randomart image is:
|
||||
+---[RSA 2048]----+
|
||||
|+=+*= + |
|
||||
|o.o=.* = |
|
||||
|.oo * o + |
|
||||
|. = + . o |
|
||||
|. o + . S |
|
||||
| . E . |
|
||||
| + o |
|
||||
| +.*o+o |
|
||||
| .o*=OO+ |
|
||||
+----[SHA256]-----+
|
||||
```
|
||||
|
||||
如果你已经创建了密钥对，你将看到以下信息。输入 ‘y’ 就会覆盖已存在的密钥。
|
||||
|
||||
```
|
||||
/home/username/.ssh/id_rsa already exists.
|
||||
Overwrite (y/n)?
|
||||
```
|
||||
|
||||
请注意**密码是可选的**。如果你输入了密码，那么每次通过 SSH 访问远程系统时都要求输入密码，除非你使用了 SSH 代理保存了密码。如果你不想要密码（虽然不安全），简单地输入两次 ENTER。不过，我们建议你使用密码。从安全的角度来看，使用无密码的 ssh 密钥对大体上不是一个很好的主意。 这种方式应该限定在特殊的情况下使用，例如，没有用户介入的服务访问远程系统。（例如，用 rsync 远程备份...）
|
||||
|
||||
如果你已经在个人文件 **~/.ssh/id_rsa** 中有了无密码的密钥对，但想要更新为带密码的密钥。使用下面的命令：
|
||||
|
||||
```
|
||||
$ ssh-keygen -p -f ~/.ssh/id_rsa
|
||||
```
|
||||
|
||||
样例输出：
|
||||
|
||||
```
|
||||
Enter new passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved with the new passphrase.
|
||||
```
|
||||
|
||||
现在，我们已经在本地系统上创建了密钥对。接下来，使用下面的命令将 SSH 公钥拷贝到你的远程 SSH 服务端上。
|
||||
|
||||
```
|
||||
$ ssh-copy-id sk@192.168.225.22
|
||||
```
|
||||
|
||||
在这，我把本地（Arch Linux）系统上的公钥拷贝到了远程系统（Ubuntu 18.04 LTS）上。从技术上讲，上面的命令会把本地系统 **~/.ssh/id_rsa.pub key** 文件中的内容拷贝到远程系统**~/.ssh/authorized_keys** 中。明白了吗？非常棒。
|
||||
|
||||
输入 **yes** 来继续连接你的远程 SSH 服务端。接着，输入远程系统 root 用户的密码。
|
||||
|
||||
```
|
||||
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
|
||||
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
|
||||
[email protected]2.168.225.22's password:
|
||||
|
||||
Number of key(s) added: 1
|
||||
|
||||
Now try logging into the machine, with: "ssh '[email protected]'"
|
||||
and check to make sure that only the key(s) you wanted were added.
|
||||
```
|
||||
|
||||
如果你已经拷贝了密钥，但想要替换为新的密码，使用 **-f** 选项覆盖已有的密钥。
|
||||
|
||||
```
|
||||
$ ssh-copy-id -f sk@192.168.225.22
|
||||
```
|
||||
|
||||
我们现在已经成功地将本地系统的 SSH 公钥添加进了远程系统。现在，让我们在远程系统上完全禁用掉基于密码认证的方式。因为，我们已经配置了密钥认证，因此我们不再需要密码认证了。
|
||||
|
||||
### 在远程系统上禁用基于密码认证的 SSH
|
||||
|
||||
你需要在 root 或者 sudo 用户下执行下面的命令。
|
||||
|
||||
为了禁用基于密码的认证，你需要在远程系统的控制台上编辑 **/etc/ssh/sshd_config** 配置文件：
|
||||
|
||||
```
|
||||
$ sudo vi /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
找到下面这一行，去掉注释然后将值设为 **no**
|
||||
|
||||
```
|
||||
PasswordAuthentication no
|
||||
```
|
||||
|
||||
重启 ssh 服务让它生效。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart sshd
|
||||
```
|
||||
|
||||
### 从本地系统访问远程系统
|
||||
|
||||
在本地系统上使用命令 SSH 你的远程服务端：
|
||||
|
||||
```
|
||||
$ ssh sk@192.168.225.22
|
||||
```
|
||||
|
||||
输入密码。
|
||||
|
||||
**样例输出：**
|
||||
|
||||
```
|
||||
Enter passphrase for key '/home/sk/.ssh/id_rsa':
|
||||
Last login: Mon Jul 9 09:59:51 2018 from 192.168.225.37
|
||||
[email protected]:~$
|
||||
```
|
||||
|
||||
现在，你就能 SSH 你的远程系统了。如你所见，我们已经使用之前 **ssh-keygen** 创建的密码登录进了远程系统的账户，而不是使用账户实际的密码。
|
||||
|
||||
如果你试图从其他客户端系统 ssh （远程系统），你将会得到这条错误信息。比如，我试图通过命令从 CentOS SSH 访问 Ubuntu 系统：
|
||||
|
||||
**样例输出:**
|
||||
|
||||
```
|
||||
The authenticity of host '192.168.225.22 (192.168.225.22)' can't be established.
|
||||
ECDSA key fingerprint is 67:fc:69:b7:d4:4d:fd:6e:38:44:a8:2f:08:ed:f4:21.
|
||||
Are you sure you want to continue connecting (yes/no)? yes
|
||||
Warning: Permanently added '192.168.225.22' (ECDSA) to the list of known hosts.
|
||||
Permission denied (publickey).
|
||||
```
|
||||
|
||||
如你所见，除了 CentOS （译注：根据上文，这里应该是 Arch） 系统外，我不能通过其他任何系统 SSH 访问我的远程系统 Ubuntu 18.04。
|
||||
|
||||
### 为 SSH 服务端添加更多客户端系统的密钥
|
||||
|
||||
这点非常重要。就像我说过的那样，除非你配置过（在之前的例子中，是 Ubuntu），否则你不能通过 SSH 访问到远程系统。如果我希望给更多客户端予以权限去访问远程 SSH 服务端，我应该怎么做？很简单。你需要在所有的客户端系统上生成 SSH 密钥对并且手动拷贝 ssh 公钥到想要通过 ssh 访问的远程服务端上。
|
||||
|
||||
在客户端系统上创建 SSH 密钥对，运行：
|
||||
|
||||
```
|
||||
$ ssh-keygen
|
||||
```
|
||||
|
||||
输入两次密码。现在， ssh 密钥对已经生成了。你需要手动把公钥（不是私钥）拷贝到远程服务端上。
|
||||
|
||||
使用命令查看公钥：
|
||||
|
||||
```
|
||||
$ cat ~/.ssh/id_rsa.pub
|
||||
```
|
||||
|
||||
应该会输出如下信息：
|
||||
|
||||
```
|
||||
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCt3a9tIeK5rPx9p74/KjEVXa6/OODyRp0QLS/sLp8W6iTxFL+UgALZlupVNgFjvRR5luJ9dLHWwc+d4umavAWz708e6Na9ftEPQtC28rTFsHwmyLKvLkzcGkC5+A0NdbiDZLaK3K3wgq1jzYYKT5k+IaNS6vtrx5LDObcPNPEBDt4vTixQ7GZHrDUUk5586IKeFfwMCWguHveTN7ykmo2EyL2rV7TmYq+eY2ZqqcsoK0fzXMK7iifGXVmuqTkAmZLGZK8a3bPb6VZd7KFum3Ezbu4BXZGp7FVhnOMgau2kYeOH/ItKPzpCAn+dg3NAAziCCxnII9b4nSSGz3mMY4Y7 ostechnix@centosserver
|
||||
```
|
||||
|
||||
拷贝所有内容（通过 USB 驱动器或者其它任何介质），然后去你的远程服务端的控制台。像下面那样，在 home 下创建文件夹叫做 **ssh**。你需要以 root 身份执行命令。
|
||||
|
||||
```
|
||||
$ mkdir -p ~/.ssh
|
||||
```
|
||||
|
||||
现在，将前几步创建的客户端系统的公钥添加进文件中。
|
||||
|
||||
```
|
||||
echo {Your_public_key_contents_here} >> ~/.ssh/authorized_keys
|
||||
```
|
||||
|
||||
在远程系统上重启 ssh 服务。现在，你可以在新的客户端上 SSH 远程服务端了。
|
||||
|
||||
如果觉得手动添加 ssh 公钥有些困难，在远程系统上暂时性启用密码认证，使用 “ssh-copy-id“ 命令从本地系统上拷贝密钥，最后关闭密码认证。
|
||||
|
||||
**推荐阅读：**
|
||||
|
||||
（译者注：在原文中此处有超链接）
|
||||
|
||||
好了，到此为止。基于密钥认证的 SSH 提供了一层防止暴力破解的额外保护。如你所见，配置密钥认证一点也不困难。这是一个非常好的方法让你的 Linux 服务端安全可靠。
|
||||
|
||||
不久我就会带来另一篇有用的文章。到那时，继续关注 OSTechNix。
|
||||
|
||||
干杯！
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/configure-ssh-key-based-authentication-linux/
|
||||
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[LuuMing](https://github.com/LuuMing)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.ostechnix.com/author/sk/
|
||||
[1]:https://www.ostechnix.com/cdn-cgi/l/email-protection
|
||||
@ -0,0 +1,74 @@
|
||||
openmediavault入门：一个家庭NAS解决方案
|
||||
======
|
||||
这个网络附加文件服务提供了一序列功能，并且易于安装和配置。
|
||||
|
||||
|
||||
|
||||
面对许多可供选择的云存储方案，一些人可能会质疑一个家庭网络附加存储服务的价值。毕竟，当所有你的文件存储在云上，你不需要为你自己云服务的维护，更新，和安全担忧。
|
||||
|
||||
但是，这不完全对，是不是？你有一个家庭网络，所以你不得不负责维护网络的健康和安全。假定你已经维护一个家庭网络，那么[一个家庭NAS][1]并不会增加额外负担。反而你能从少量的工作中得到许多的好处。
|
||||
|
||||
你可以为你家里所有的计算机备份(你也可以备份离线网站).构架一个存储电影，音乐和照片的媒体服务器，无需担心网络连接是否连接。在家里的多台计算机处理大型文件，不需要等待从网络其他随机的计算机传输这些文件过来。另外，可以让NAS与其他服务一起进行双重任务，如托管本地邮件或者家庭Wiki。也许最重要的是，构架家庭NAS，数据完全是你的，始终在控制下和随时可访问的。
|
||||
|
||||
接下来的问题是如何选择NAS方案。当然，你可以购买预先建立的解决方案，并在某一天打电话购买，但是这会有什么乐趣呢？实际上，尽管拥有一个能处理一切的设备很棒，但最好还是有一个可以修复和升级的钻机。这是一个我近期发现的解决方案。我选择安装和配置[openmediavault][2]。
|
||||
|
||||
### 为什么选择openmediavault?
|
||||
|
||||
市面上有不少开源的NAS解决方案，其中有些无可争议的比openmediavault流行。当我询问周遭，例如，[freeNAS][3]最常被推荐给我。那么为什么我不采纳他们的建议呢？毕竟，它被大范围的使用，包含很多的功能，并且提供许多支持选项，[基于FreeNAS官网的一份对比数据][4]。当然这些全部是对的。但是openmediavault也不差。它是基于FreeNAS早期版本，虽然它在下载和功能方面的数量较低，但是对于我的需求而言，它已经相当足够了。
|
||||
|
||||
另外一个因素是它让我感到很舒适。openmediavault的底层操作系统是[Debian][5],然而FreeNAS是[FreeBSD][6]。由于我个人对FressBSD不是很熟悉，因此如果我的NAS出现故障，必定会很难在FreeBSD上修复故障。同样的，也会让我觉得很难微调配置或添加服务到机器上。当然，我可以学习FreeBSD和更熟悉它，但是我已经在家里构架了这个NAS；我发现，如果限制给定自己完成构建NAS的“学习机会”的数量，构建NAS往往会更成功。
|
||||
|
||||
当然，每个情况都不同，所以你要自己调研，然后作出最适合自己方案的决定。FreeNAS对于许多人似乎都是不错的解决方案。Openmediavault正是适合我的解决方案。
|
||||
|
||||
### 安装与配置
|
||||
|
||||
在[openmediavault文档]里详细记录了安装步骤，所以我不在这里重述了。如果你曾经安装过任何一个linux版本，大部分安装步骤都是很类似的(虽然在相对丑陋的[Ucurses][9]界面，不像你可能在现代版本的相对美观的安装界面)。我通过使用[专用驱动器][9]指令来安装它。然而，这些指令不但很好，而且相当精炼的。当你搞定这些指令，你安装了一个基本的系统，但是你还需要做很多才能真正构建好NAS来存储任何文件。例如，专用驱动器指令在硬盘驱动上安装openmediavault，但那是操作系统的驱动，而不是和网络上其他计算机共享空间的那个驱动。你需要自己把这些建立起来并且配置好。
|
||||
|
||||
你要做的第一件事是加载用来管理的网页界面和修改默认密码。这个密码和之前你安装过程设置的根密码是不同的。这是网页洁面的管理员账号，和默认的账户和密码分别是 `admin` 和 `openmediavault`，当你登入后自然而然地会修改这些配置属性。
|
||||
|
||||
#### 设置你的驱动
|
||||
|
||||
一旦你安装好openmediavault,你需要它为你做一些工作。逻辑上的第一个步骤是设置好你即将用来作为存储的驱动。在这里，我假定你已经物理上安装好它们了，所以接下来你要做的就是让openmediavault识别和配置它们。第一步是确保这些磁盘是可见的。侧边栏菜单有很多选项，而且被精心的归类了。选择**存储 - > 磁盘**。一旦你点击该菜单，你应该能够看到所有你已经安装到该服务器的驱动，包括那个你已经用来安装openmediavault的驱动。如果你没有在那里看到所有驱动，点击扫描按钮去看它能够接载它们。通常，这不会是一个问题。
|
||||
|
||||
当你的文件共享时，你可以独立的挂载和设置这些驱动，但是对于一个文件服务器，你将想要一些冗余驱动。你想要能够把很多驱动当作一个单一卷和能够在某一个驱动出现故障或者空间不足下安装新驱动的情况下恢复你的数据。这意味你将需要一个[RAID][10]。你想要的什么特定类型的RAID的主题是一个深深的兔子洞，是一个值得另写一片文章专门来讲述它(而且已经有很多关于该主题的文章了)，但是简而言之是你将需要不仅仅一个驱动和最好的情况下，你的所有驱动都存储一样数量的数据。
|
||||
|
||||
openmedia支持所有标准的RAID级别，所以多了解RAID对你很有好处的。可以在**存储 - > RAID管理**配置你的RAID。配置是相当简单:点击创建按钮，在你的RAID阵列里选择你想要的磁盘和你想要使用的RAID级别，和给这个阵列一个名字。openmediavault为你处理剩下的工作。没有混乱的命令行，试图记住‘mdadm'命令的一些标志参数。在我特别的例子，我有六个2TB驱动，并被设置为RAID 10.
|
||||
|
||||
当你的RAID构建好了，基本上你已经有一个地方可以存储东西了。你仅仅需要设置一个文件系统。正如你的桌面系统，一个硬盘驱动在没有格式化情况下是没什么用处的。所以下一个你要去的地方的是位于openmediavault控制面板里的 **存储 - > 文件系统**。和配置你的RAID一样，点击创建按钮，然后跟着提示操作。如果你只有一个RAID在你的服务器上，你应该可以看到一个像 `md0`的东西。你也需要选择文件系统的类别。如果你不能确定，选择标准的ext4类型即可。
|
||||
|
||||
#### 定义你的共享
|
||||
|
||||
亲爱的！你有个地方可以存储文件了。现在你只需要让它在你的家庭网络中可见。可以从在openmediavault控制面板上的**服务**部分上配置。当谈到在网络上设置文件共享，有两个主要的选择:NFS或者SMB/CIFS. 根据以往经验，如果你网络上的所有计算机都是Linux系统，那么你使用NFS会更好。然而，当你家庭网络是一个混合环境，是一个包含Linux，Windows，苹果系统和嵌入式设备的组合，那么SMB/CIF可能会是你合适的选择。
|
||||
|
||||
这些选项不是互斥的。实际上，你可以在服务器上运行这些服务和同时拥有这些服务的好处。或者你可以混合起来，如果你有一个特定的设备做特定的任务。不管你的使用场景是怎样，配置这些服务是相当简单。点击你想要的服务，从它配置中激活它，和在网络中设定你想要的共享文件夹为可见。在基于SMB/CIFS共享的情况下，相对于NFS多了一些可用的配置，但是一般用默认配置就挺好的，接着可以在默认基础上修改配置。最酷的事情是它很容易配置，同时也很容易在需要的时候修改配置。
|
||||
|
||||
#### 用户配置
|
||||
|
||||
基本上已将完成了。你已经在RAID配置你的驱动。你已经用一种文件系统格式化了RAID。和你已经在格式化的RAID上设定了共享文件夹。剩下来的一件事情是配置那些人可以访问这些共享和可以访问多少。这个可以在 **访问权限管理** 配置区设置。使用 **用户** 和 **群组** 选项来设定可以连接到你共享文件加的用户和设定这些共享文件的访问权限。
|
||||
|
||||
一旦你完成用户配置，你几乎准备好了。你需要从不同客户端机器访问你的共享，但是这是另外一个可以单独写个文章的话题了。
|
||||
|
||||
玩得开心！
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/9/openmediavault
|
||||
|
||||
作者：[Jason van Gumster][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[jamelouis](https://github.com/jamelouis)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mairin
|
||||
[1]: https://opensource.com/article/18/8/automate-backups-raspberry-pi
|
||||
[2]: https://openmediavault.org
|
||||
[3]: https://freenas.org
|
||||
[4]: http://www.freenas.org/freenas-vs-openmediavault/
|
||||
[5]: https://www.debian.org/
|
||||
[6]: https://www.freebsd.org/
|
||||
[7]: https://openmediavault.readthedocs.io/en/latest/installation/index.html
|
||||
[8]: https://invisible-island.net/ncurses/
|
||||
[9]: https://openmediavault.readthedocs.io/en/latest/installation/via_iso.html
|
||||
[10]: https://en.wikipedia.org/wiki/RAID
|
||||
Loading…
Reference in New Issue
Block a user