Skip to content

Commit

Permalink
refactor: 💡 moved to own file permission and ownership reference doc …
Browse files Browse the repository at this point in the history 
…and created separate key not found ref linking to it
  • Loading branch information
@heldrida
heldrida committed Sep 12, 2023
1 parent a453a87 commit 77ee73e
Show file tree
Hide file tree
Showing 2 changed files with 200 additions and 175 deletions.
192 changes: 192 additions & 0 deletions references/Lightning CLI/file-permissions-and-ownership.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,192 @@
---
title: File permissions and Ownership
slug: file-permissions-and-owernship
hide_title: true
tags:
- ownership
- file permissions
- sudoer
- root
---

<!--
The following import is intentional (see partial <CheckoutCommitWarning />)
-->
import Author from '@site/src/components/Author';

## Ownership

The user who installs the Fleek Network Lightning CLI matters, as it can own or delegate ownership of the dependencies and applications being installed.

For example, if you have followed the install document recommendations and have:
- Created a user **lgtn**
- Switched to the user **lgtn**
- Executed the installation process as **lgtn**

You'll find that it owns the following directories under the user home (/home/lgtn):

```sh
drwxr-x--- 6 lgtn lgtn 4096 Sep 12 10:27 .
drwxr-xr-x 3 root root 4096 Sep 11 12:28 ..
drwxrwxr-x 5 lgtn lgtn 4096 Sep 11 12:29 .cargo
drwxrwxr-x 5 lgtn lgtn 4096 Sep 11 15:25 .lightning
drwxrwxr-x 6 lgtn lgtn 4096 Sep 11 12:29 .rustup
drwxrwxr-x 3 lgtn lgtn 4096 Sep 11 12:28 fleek-network
```

Above, we have the listing properties set as **drwxrwxr-x** and the ownership **lgtn:lgtn**.

On the other hand, if you have done the installation process as **root** superuser, you'll find that:
- The location of the directories and files goes under the `/root` pathname
- The ownership is set to **root:root**

Learn more about [file permissions](https://www.linuxfoundation.org/blog/blog/classic-sysadmin-understanding-linux-file-permissions) from the [Linux Foundation](https://www.linuxfoundation.org/).

To learn more about file permission on Linux, read the [Understanding Linux File Permissions](https://www.linuxfoundation.org/blog/blog/classic-sysadmin-understanding-linux-file-permissions).

## Using sudo to delegate permissions

Consider file ownership and permissions to understand where the keystore is located. Take close attention when executing commands as an admin–with or without **super user** (root) or **sudo**.

If a command is executed without **sudo** then the generated output goes onto the **user** home.

```sh
lgtn keys generate
```

Resulting in having the **keystore** saved onto `/home/username/.lightning/keystore`.

On the other hand, if a command is executed with **sudo** then the generated output is delegated to **root** directory.

```sh
sudo lgtn keys generate
```

Resulting in having the **keystore** saved onto `/root/.lightning/keystore`.

## User $HOME directory

The home directory is a directory that contains the personal files of a particular user of the system. On Linux, the `$HOME` environment variable is set by the login program, which sets the user `$HOME`` accordingly. A user's home goes by the username, the user who's logged in.

For this reason, a user can change to the home directory by executing:

```sh
cd $HOME
```

A shorthand allows a user to refer to their home directory simply as `~` (tilde), as follows:

```sh
cd ~
```

:::tip
We can find that the HOME or ~ (tilde) is highly dependent on the user who's logged in. Since we know that the user might delegate to **root** by the usage of **sudo**, this can help troubleshoot and explain the location of our files e.g. the keystore. In the section [Set the locations of the user paths](#set-the-locations-of-the-user-paths), we learn how to define the location of our user configuration paths to avoid confusion. By doing it we ensure that when running the service, the service picks the correct configuration paths for our user.
:::

To learn more about the user $HOME directory read the wikipedia [Home directory](https://en.wikipedia.org/wiki/Home_directory) document.

## Set the locations of the user paths

In the `/home/<USERNAME>/.lightning/config.toml` you'll find some and more of the following:

```toml
[BLANK]

[application]
db_path = "~/.lightning/data/app_db"

[consensus]
store_path = "~/.lightning/data/narwhal_store"

[fsstore]
root = "~/.lightning/blockstore"

[resolver]
store_path = "~/.lightning/data/resolver_store"

[signer]
consensus_key_path = "~/.lightning/keystore/consensus.pem"
node_key_path = "~/.lightning/keystore/node.pem"
```

:::tip
The configuration properties and values presented above are a shorter version of what you'll find on your **configuration.toml**. We keep it short to make it easier to follow, do not copy and paste.
:::

Find and replace all instances of ~ in the config file `/home/<USERNAME>/.lightning/config.toml`.

Here's an example of how to do it using **sed**:

```sh
sed -i "s|~/.lightning|/home/<USERNAME>/.lightning|g" "/home/<USERNAME>/.lightning/config.toml"
```

:::tip
Replace the `<USERNAME>` with your username. For example, if you have followed the recommendation to [create a user](/docs/node/install#create-a-user) it would look like `/home/lgtn/.lightning/config.toml` for the username **lgtn**.
:::

## Set the configuration flag -c on the service unit file

The following section assumes that a System service unit has been declared and you're using systemctl to control the service, as described in our [Systemd Service Setup](/docs/node/install#systemd-service-setup) install section.

Open and edit the **/etc/systemd/system/lightning.service** file.

1) Replace `<USERNAME>` with YOUR username. For example, in the documentation we use the username **lgtn**, which means we'd replace `User=<USERNAME>` with `User=lgtn`.

2) Make sure that the ExecStart is set correctly, including the `-c`

```sh
[Unit]
Description=Fleek Network Node lightning service

[Service]
User=<USERNAME>
Type=simple
MemoryHigh=32G
RestartSec=15s
Restart=always
ExecStart=lgtn -c /home/<USERNAME>/.lightning/config.toml run
StandardOutput=append:/var/log/lightning/output.log
StandardError=append:/var/log/lightning/diagnostic.log
Environment=TMPDIR=/var/tmp

[Install]
WantedBy=multi-user.target
```

For our example, as the username **lgtn** it would look like:

```sh
[Unit]
Description=Fleek Network Node lightning service

[Service]
User=lgtn
Type=simple
MemoryHigh=32G
RestartSec=15s
Restart=always
ExecStart=lgtn -c /home/lgtn/.lightning/config.toml run
StandardOutput=append:/var/log/lightning/output.log
StandardError=append:/var/log/lightning/diagnostic.log
Environment=/var/tmp

[Install]
WantedBy=multi-user.target
```

When complete make sure the file is saved and the systemctl daemon is reloaded, as follows:

```sh
sudo systemctl daemon-reload
```

Consequently, when a user manages the service via the systemctl, the Lightning CLI process will read the configuration file settings provided above. It includes the location of the user preferences, such as the keystore location amongst others, preventing confusion regardless of **root** delegation.

<Author
name="Helder Oliveira"
image="https://github.com/heldrida.png"
title="Software Developer + DX"
url="https://github.com/heldrida"
/>
183 changes: 8 additions & 175 deletions references/Lightning CLI/keys-not-found.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,184 +9,17 @@ tags:
- file permissions
---

<!--
The following import is intentional (see partial <CheckoutCommitWarning />)
-->
import Author from '@site/src/components/Author';
## Node key does not exist

## Ownership

The user who installs the Fleek Network Lightning CLI matters, as it can own or delegate ownership of the dependencies and applications being installed.

For example, if you have followed the install document recommendations and have:
- Created a user **lgtn**
- Switched to the user **lgtn**
- Executed the installation process as **lgtn**

You'll find that it owns the following directories under the user home (/home/lgtn):

```sh
drwxr-x--- 6 lgtn lgtn 4096 Sep 12 10:27 .
drwxr-xr-x 3 root root 4096 Sep 11 12:28 ..
drwxrwxr-x 5 lgtn lgtn 4096 Sep 11 12:29 .cargo
drwxrwxr-x 5 lgtn lgtn 4096 Sep 11 15:25 .lightning
drwxrwxr-x 6 lgtn lgtn 4096 Sep 11 12:29 .rustup
drwxrwxr-x 3 lgtn lgtn 4096 Sep 11 12:28 fleek-network
```

Above, we have the listing properties set as **drwxrwxr-x** and the ownership **lgtn:lgtn**.

On the other hand, if you have done the installation process as **root** superuser, you'll find that:
- The location of the directories and files goes under the `/root` pathname
- The ownership is set to **root:root**

Learn more about [file permissions](https://www.linuxfoundation.org/blog/blog/classic-sysadmin-understanding-linux-file-permissions) from the [Linux Foundation](https://www.linuxfoundation.org/).

To learn more about file permission on Linux, read the [Understanding Linux File Permissions](https://www.linuxfoundation.org/blog/blog/classic-sysadmin-understanding-linux-file-permissions).

## Using sudo to delegate permissions

Consider file ownership and permissions to understand where the keystore is located. Take close attention when executing commands as an admin–with or without **super user** (root) or **sudo**.

If a command is executed without **sudo** then the generated output goes onto the **user** home.

```sh
lgtn keys generate
```

Resulting in having the **keystore** saved onto `/home/username/.lightning/keystore`.

On the other hand, if a command is executed with **sudo** then the generated output is delegated to **root** directory.

```sh
sudo lgtn keys generate
```

Resulting in having the **keystore** saved onto `/root/.lightning/keystore`.

## User $HOME directory

The home directory is a directory that contains the personal files of a particular user of the system. On Linux, the `$HOME` environment variable is set by the login program, which sets the user `$HOME`` accordingly. A user's home goes by the username, the user who's logged in.

For this reason, a user can change to the home directory by executing:

```sh
cd $HOME
```

A shorthand allows a user to refer to their home directory simply as `~` (tilde), as follows:

```sh
cd ~
```

:::tip
We can find that the HOME or ~ (tilde) is highly dependent on the user who's logged in. Since we know that the user might delegate to **root** by the usage of **sudo**, this can help troubleshoot and explain the location of our files e.g. the keystore. In the section [Set the locations of the user paths](#set-the-locations-of-the-user-paths), we learn how to define the location of our user configuration paths to avoid confusion. By doing it we ensure that when running the service, the service picks the correct configuration paths for our user.
:::

To learn more about the user $HOME directory read the wikipedia [Home directory](https://en.wikipedia.org/wiki/Home_directory) document.

## Set the locations of the user paths

In the `/home/<USERNAME>/.lightning/config.toml` you'll find some and more of the following:

```toml
[BLANK]

[application]
db_path = "~/.lightning/data/app_db"

[consensus]
store_path = "~/.lightning/data/narwhal_store"

[fsstore]
root = "~/.lightning/blockstore"

[resolver]
store_path = "~/.lightning/data/resolver_store"

[signer]
consensus_key_path = "~/.lightning/keystore/consensus.pem"
node_key_path = "~/.lightning/keystore/node.pem"
```

:::tip
The configuration properties and values presented above are a shorter version of what you'll find on your **configuration.toml**. We keep it short to make it easier to follow, do not copy and paste.
:::

Find and replace all instances of ~ in the config file `/home/<USERNAME>/.lightning/config.toml`.

Here's an example of how to do it using **sed**:

```sh
sed -i "s|~/.lightning|/home/<USERNAME>/.lightning|g" "/home/<USERNAME>/.lightning/config.toml"
```

:::tip
Replace the `<USERNAME>` with your username. For example, if you have followed the recommendation to [create a user](/docs/node/install#create-a-user) it would look like `/home/lgtn/.lightning/config.toml` for the username **lgtn**.
:::

## Set the configuration flag -c on the service unit file

The following section assumes that a System service unit has been declared and you're using systemctl to control the service, as described in our [Systemd Service Setup](/docs/node/install#systemd-service-setup) install section.

Open and edit the **/etc/systemd/system/lightning.service** file.

1) Replace `<USERNAME>` with YOUR username. For example, in the documentation we use the username **lgtn**, which means we'd replace `User=<USERNAME>` with `User=lgtn`.

2) Make sure that the ExecStart is set correctly, including the `-c`

```sh
[Unit]
Description=Fleek Network Node lightning service

[Service]
User=<USERNAME>
Type=simple
MemoryHigh=32G
RestartSec=15s
Restart=always
ExecStart=lgtn -c /home/<USERNAME>/.lightning/config.toml run
StandardOutput=append:/var/log/lightning/output.log
StandardError=append:/var/log/lightning/diagnostic.log
Environment=TMPDIR=/var/tmp

[Install]
WantedBy=multi-user.target
```

For our example, as the username **lgtn** it would look like:

```sh
[Unit]
Description=Fleek Network Node lightning service

[Service]
User=lgtn
Type=simple
MemoryHigh=32G
RestartSec=15s
Restart=always
ExecStart=lgtn -c /home/lgtn/.lightning/config.toml run
StandardOutput=append:/var/log/lightning/output.log
StandardError=append:/var/log/lightning/diagnostic.log
Environment=/var/tmp

[Install]
WantedBy=multi-user.target
```

When complete make sure the file is saved and the systemctl daemon is reloaded, as follows:
When watching the Fleek Network Lightning service log output, you find the "Node key does not exist" message placed recursively. As follows:

```sh
sudo systemctl daemon-reload
thread 'main' panicked at 'Node key does not exist. Use CLI to generate keys.', core/node/src/testnet_sync.rs:126:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'Node key does not exist. Use CLI to generate keys.', core/node/src/testnet_sync.rs:126:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

Consequently, when a user manages the service via the systemctl, the Lightning CLI process will read the configuration file settings provided above. It includes the location of the user preferences, such as the keystore location amongst others, preventing confusion regardless of **root** delegation.
If you haven't deleted the keystore and can locate it, it's due to how the service is being run. As a user can delegate (sudo) the execution of the process to **root**, the location of the keystore differs on runtime.

<Author
name="Helder Oliveira"
image="https://github.com/heldrida.png"
title="Software Developer + DX"
url="https://github.com/heldrida"
/>
To learn more about how file permissions and ownership work, you're advised to read the reference document [here](/references/Lightning%20CLI/file-permissions-and-ownership.md).

0 comments on commit 77ee73e

Please sign in to comment.