summaryrefslogtreecommitdiff
path: root/README.md
blob: 0e0da22b7e260f3270be790fcaf687334d6007fb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
VyOS toplevel build
===================

# WARNING

This repository is for building the VyOS version that is to become 1.2.0 and that is currently in beta testing.
For 1.1.x, use the build-iso repository.


# What is VyOS

VyOS is an open source operating system for network devices (routers, firewalls and so on).
If you want to use it in your network, check out download and installation instructions at https://vyos.io

If you want to modify VyOS and/or join its development, read on.

VyOS is not new. It is a fork of Vyatta Core that was created when the open source version of it was
discontinued. If you are a Vyatta Core user, you can upgrade your installation to VyOS.

# What is this repository?

VyOS is a GNU/Linux distribution based on Debian. Just like any other distribution, it consists of multiple
packages.

Some packages are taken from the upstream, while other are modified or written from scratch by VyOS developers.
Every package maintained by the VyOS team has its own git repository. VyOS image build is therefore a multi-step
process. Packages are compiled first, then an ISO is built from Debian packages and our own packages.

This is the top level repository that contains links to repositories with VyOS-specific packages (organized
as git submodules) and scripts and data that are used for building those packages and the installation image.

# Structure of this repository

There are several directories with their own purpose:

    build/    Used for temporary files used for the build and for build artifacts
    scripts/  Contains scripts that are used for the build process
    data/     Contains data required for buildng the ISO (such as boot splash)
    tools/    Contains scripts that are used for maintainer's tasks automation
              and other purposes, but not in ISO build process

# Building VyOS installation images

## Prerequisites

To build a VyOS image, you need a machine that runs Debian Jessie. Other build hosts are not supported.

Several packages are required for building the ISO and all packages, namely python3, live-build, pbuilder, python3-pystache and devscripts.
Individual packages may have other build dependencies. If some packages are missing, build scripts will tell you.
## Building the ISO image inside a docker container

Using Dockerfile you can create your own docker container that can be used to build a VyOS ISO image.
The Dockerfile contains some of the most used packages needed for a VyOs build ISO process.

```
squashfs-tools           # Required for squashfs file system
git                      # Required, for cloning the source
autoconf                 # Required, for generating build scripts
dpkg-dev                 # Required, used in build scripts
live-helper              # Required, for ISO build
syslinux                 # Required, for ISO build
genisoimage              # Required, for ISO build
make                     # Required, for ISO build
lsb-release              # Required, used by configure script
fakechroot               # Required, for ISO build
devscripts               # Optional, for building submodules (kernel etc)
kernel-package           # Optional, for building the kernel
libtool                  # Optional, for building certain packages (eg vyatta-op-vpn)
libglib2.0-dev           # Optional, for building vyatta-cfg 
libboost-filesystem-dev  # Optional, for building vyatta-cfg
libapt-pkg-dev           # Optional, for building vyatta-cfg
flex                     # Optional, for building vyatta-cfg
bison                    # Optional, for building vyatta-cfg
libperl-dev              # Optional, for building vyatta-cfg
libnfnetlink-dev         # Optional, for building vyatta-cfg-vpn
vim                      # Optional, vim, vi, nano or other text editor
```

To build the docker image

```
docker build -t vyos-builder $PATH_TO_Dockerfile
```

To run the docker image:

```
docker run --privileged -v /HOST_PATH/images:/vyos --name=vyos_node_builder -d vyos-builder bash
```
* docker container must be run with --privileged flag
* is recommended to run the container with a volume mapped in order to easy export built VyOs ISO images 
to the "external" world

To connect to the docker image once is running:
```
docker exec -it vyos_node_builder bash
```

After the docker container is running you can git clone the vyos-build repository inside the container 
and follow up the bellow instructions in order to build the VyOs ISO image 

## Building the ISO image

Before you can build an image, you need to configure your build. 

To build an image, use the following commands:

```
./configure
make iso
```

The ./configure script has a number of options that you can see by calling it with --help

## Building the images for virtualization platforms

* QEMU

Run following command after building the ISO image.

```
make qemu
```

* VMware

Run following command after building the QEMU image.

```
make vmware
```

# Development process

## git branches

The default branch that contains the most recent VyOS code is called 'current' rather than 'master'.
We know if'ts confusing, but it's not easy to fix.
In a nutshell, the code we inherited from Vyatta Core had its master branch so out of sync with everything
it was beyong any repair. Vyatta developers used to create a new branch not when a release is ready for
code freeze, but rather before starting to work on a new release.
This is hard to change in existing code, so this is just the way it is, for now.

All new code goes to the 'current' branch. When it's time for a code freeze, a new branch is created
for the release, and new code from 'current' is backported to the release branch as needed.

For branch naming we use chemical elements (hydrogen, helium, ...).