Hi all!
I’d like to report that building the GCE image of equuleus VyOs branch with vyos-build git repository does introduce some bug/regression. By running that image on a GCE VM I cannot login as vyos/vyos user (tested on serial console).
I had to boot that image into Password Recovery mode, reset the password and then I’m able to get access to the VM.
Can anyone help?
Moreover, what’s the suggested way to edit the default configuration file that is applied on the GCE image? I tried editing “./data/live-build-config/includes.chroot/opt/vyatta/etc/config.boot.default” before issuing the “sudo make GCE” command, but the default config applied at boot (on GCE VM) is not the one I edited.
Note: I’ve built the image using the ubuntu GitHub actions runner.
You have to use a cloud-init configuration
It doesn’t have any sense to use default user for cloud images
2 Likes
Hi and thanks for the answer.
I thought about that, however I still miss how to load/pre-configure the cloud-init file at build time/run time.
According to the documentation here, we are able to provide the cloud-init specs at boot time via 3 different ways:
-metadata
-Network conf
-user-data
The rest of the documentation describes only one of them (user-data) but does not specify how to inject that data via the cloud provider. If I have to guess, on GCP, I’d say to use the metadata server to pass such info. However, it is still unclear what metadata key should be used and what text/conf should be placed into the metadata value (plain text? Base64 encoded gzip?). Moreover, the image built via equuleus does not configure any network interface, so I doubt the instance will be able to reach the metadata server to fetch that file at boot time.
One last thing: the documentation clearly states that in case of missing cloud-init specs, the login will fallback to vyos/vyos: that is not happening. So either the documentation is unclear, or there’s a bug in the built image.
As a side note, today I tried adding the metadata configuration from the GCP console and tested.
As I was suspecting, from the boot log of the serial console, we clearly see that the VM is unable to resolve the metadata server and, therefore, unable to fetch the configuration (assuming I have correctly added the metadata via custom-metadata on GCP).
Please refer to the following screenshots:
Any thoughts?
EDIT: Some more info.
After looking at Makefile, I realized that the default configuration file was being overwritten by the one contained into tools/cloud-init. Therefore, at build time, I am editing that default boot.config file so that it looks similar to the following:
interfaces {
ethernet ens4 {
address dhcp
}
loopback lo {
}
}
system {
config-management {
commit-revisions 100
}
conntrack {
modules {
ftp
h323
nfs
pptp
sip
sqlnet
tftp
}
}
console {
device ttyS0 {
speed 38400
}
}
host-name vyos-gce
login {
user vyos {
authentication {
encrypted-password $6$gf2ShN8QhLqyH$WedSwHWXMYgC/qoM7ibe2XwdZro.A.qsYqMH0P9jf5opselu31ACTUD1bkRTL8S3WeKjoJ1Uu2xOgZXSV9SOr1
plaintext-password ""
}
}
}
name-server 169.254.169.254
name-server 8.8.8.8
name-server 8.8.4.4
ntp {
server time1.vyos.net {
}
server time2.vyos.net {
}
server time3.vyos.net {
}
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}
}
By doing so, the VM correctly fetches its IP address and starts cloud-init. In other words, this means the problem is with the current version of equuleus that won’t correctly bind any interface on GCE, preventing the cloud-init from working as expected, as the metadata server won’t be reached without minimal IP configuration. Also, by adding a vyos/vyos user/password, I was able to let someone log-in with serial console: without that, nobody could work with the provided image without resetting its password first.
