# Installing Tezos/Octez Using Debian Packages
When it comes to installing software, especially for critical applications like Tezos/Octez, it's crucial to ensure a secure and stable environment. While compiling from source can provide customization options, it often introduces complexities and risks. Instead, opting for binary packages from a trusted source simplifies installation and enhances security.
Nomadic Labs took over the amazing work of Serokell and we now provide Debian packages for a Ubuntu and Debian distribution for the last two LTS releases.
## Why Use Binary Packages?
Binary packages compiled for a specific platform, should be always preferred over source or statically compiled packages. These packages can be used to simplify the creation of OCI images or deployed on bare metal.
Using binary packages offers several advantages:
- **Security**: Binary packages are pre-compiled and thoroughly tested, reducing the risk of vulnerabilities introduced during compilation. All our packages are signed and our supply chain is strictly monitored to make sure the package that we delivered only uses components that were vetted by our engeneering team.
- **Stability**: Binaries from a trusted repository undergo rigorous testing, ensuring stability and compatibility with the target system. We make sure to compile our binaries in a clean environenment and using an up-to-date software distribution. We use LTS distribution to enhance stability and reduce the attack surface.
- **Ease of Installation**: Binary packages can be installed using standard package management tools, streamlining the process. Apt is ubiquitous in the debian world. It allow us to sign our packages and for the end user to automatically verify it's installation. We provide packages that allow the end user to easily tailor their installation for different use cases.
- **Reduced Downtime**: With reliable binaries and straightforward installation, system downtime due to installation errors or compatibility issues are minimized. We carefully test the upgrade process of our packages to make sure the end can enjoy a click and go upgrade process with near to zero downtime.
## Installing Tezos/Octez
To install Tezos/Octez using Debian packages, there are a few preliminary steps we need to follow.
### 1. Add Tezos Repository
First, we need to make sure that we are using a supported ditribution and release. Our packages are specifically tailored for each distrbution and trying to install them on a different system might result in a installation problem, or our software might misbehave at runtime. To make things concrete, here we are going to use `debian` a distribution and `bookworm` as release.
To add the Nomadic Labs repository to your package sources list:
```shell
$ export REPO="deb [arch=amd64] https://tezos-linux-repo-dev.storage.googleapis.com/debian bookworm main"
$ apt install -y sudo gpg curl
$ curl "https://tezos-linux-repo-dev.storage.googleapis.com/debian/octez.asc"
$ sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/octez.gpg
$ echo "$REPO" > /etc/apt/sources.list.d/octez.list
$ apt-get update
```
At this point, apt should be able to download, verify the signature and install octez packages.
You can verify this by searching for `octez-` packages using `apt search octez`.
### 2. Install Octez Packages
Once the repository is added, install the Octez packages is as easy as:
```shell
$ sudo apt-get install -y octez-node octez-client octez-baker
```
Notice that here, for the sake of clarity we spell out the name of all packages. However to install a L1 stack for the Tezos blockchain it is only necessary to install the `octez-baker` and the dependency graph will pull all the required dependencies, that is the `octez-node`, the `octez-client` and the zero knownledge parameters needed to run the node.
### 3. Verify Installation
After installation, verify that Tezos/Octez components are installed correctly:
```shell
$ octez-node --version
$ octez-client --version
$ octez-baker --version
```
These binaries can be used with any user. However, to run octez in production our package sets up a special user named `tezos` to run all daemons via systemd and without direct user intervention.
### Enabling Systemd Daemons
To ensure that Octez services start automatically on system boot and can be managed using systemd, we need to enable the `systemd` services. These services are installed by apt but left disabled by default.
For example to enable the octez node systemd service:
```shell
sudo systemctl enable octez-node
```
Similarly we can do the same with the baker.
### Configuring the node and the baker.
Octez packages provide a very basic configuration in `/etc/defaults/octez-*` files. These are to be read as configuration files for the systemd services. We took a non-opinionated approach regarding the basic configuration provided by default. We do not make assumption on the setup of the machine or try to imagine all possible user cases. To create more advanced configuration the user can directly configure each daemon using the following command :
```shell
sudo su tezoc -c "octez-node config ..."
```
and specifying the octez node configuration options. A complete guide on how to configure the tezos node can be found on this page: https://tezos.gitlab.io/user/setup-node.html
### Running the octez-node
Once the node is configured, we can use systemd command-line tool to start the daemon as
```shell
$ sudo systemctl start octez-node
```
We can also check the status of the daemon or the logs of the node that are stored by default in `/var/log/tezoz/octez-node.log`. Logs are automatically rotated using `logrotate`.
## Configuring the baker
The octez-baker can be configured in a similar way. However, because of the sensitive nature of the private keys needed by the baker to function, we suggest a slightly more involved configuration procedure using the octez-signer.
First, as the login user, we must create a set of keys. These are the private keys that will be entrusted to the signer to actually sign operations on behalf of the baker. The signer will run in a different process (possibly on a separate host), and ideally using a hardware enclave such as a hardware ledger. For the sake of brevity, in this example, the keys will be simply stored on the disk, but this is not a recommended setting for a production baker.
We create an authentication key that is going to be used to authenticate the baker with the signer, and a signing key to sign the operations.
```shell
# create a signing key
$ octez-signer gen keys alice
# create a authentication key
$ octez-client gen keys auth
$ octez-signer show address auth
Hash: tz1V7TgBR52wAjjqsh24w8y9CymFGdegt9qs
Public Key: edpk123456789....
# add the auth key to the octez-signer. This is the default options set in the octez-signer.service file
$ octez-signer add authorized key edpk123456789... --name auth
```
Now we need to configure the `octez-signer`. We use again systemd and we run a user service. The `octez-signer.service` file can be customized by the user to allow for more complex and secure scenarios.
```shell
# install the signer service
$ mkdir -p ~/.config/systemd/user/
$ cp /usr/share/doc/octez-signer/octez-signer.service ~/.config/systemd/user/
# start the service
$ systemctl --user start octez-signer
# examine the logs
$ journalctl --user-unit octez-signer
```
Now that the signer is running, we need to configure the baker.
```shell
# Get the tz1 address of our signing key
$ octez-signer show address alice
Hash: tz1V7TgBR52wAjjqsh24w8y9CymFGdegt9qs
Public Key: edpkvGAz71r8SZomcvF7LGajXT3AnhYX9CrmK3JWgA2xk8rf8CudY8
# Configure the baker to use the remote signer
sudo su tezos -c "octez-client -R tcp://localhost:7732 import secret key alice remote:tz1V7TgBR52wAjjqsh24w8y9CymFGdegt9qs"
```
Now that everything is in place, as for the node, we can first enable, then start the `octez-baker`.
```shell
sudo systemdctl enable octez-baker-current.service
sudo systemdctl start octez-baker-current.service
```
The logs of the baker are available in `/var/logs/tezos/octez-baker-current.log`
Notice that the `octez-baker` package installs two services, `octez-baker-current` and `octez-baker-next` respectively associated with the current protocol and the next proposed protocol upgrade. The name of the protocols associated with these daemons are specifified in `/etc/default/octez-baker-*` files. The `octez-baker-next` baker should be used for testing and during a protocol upgrade. Running the `octez-baker-next` together with the `octez-baker-current` is possible and recomended to avoid downtime.
### Upgrading Tezos/Octez
To upgrade Tezos/Octez to the latest version, we can simply following these steps:
```shell
sudo apt-get update
sudo apt-get upgrade
```
Or alternatively, we can select only to upgrade the `octez-*` packages.
```shell
sudo apt-get upgrade octez-node octez-client octez-baker
```
When necessary the upgrade scripts will make the user aware of breaking changes and required actions such as new configuration parameters or changes in governance.