Arch Linux User Repository

Community LICENSE file has been moved (referenced in PKGBUILD): https://github.com/gravitational/teleport/commit/de8133d66da36b8b3e5c8d71177b3ce2a27df593

@shulhan you're right, that is outdated. They should be updated now in 15.3.5-2.

@axionl The systemd service file is quite odd and questionable. In fact it does not run if I use it directly.

# cat /etc/systemd/system/multi-user.target.wants/teleport.service
[Unit]
Description=Teleport SSH Service
After=network.target

[Service]
Type=simple
Restart=on-failure
WorkingDirectory=/etc/teleport
EnvironmentFile=-/etc/teleport/teleport-env.conf
ExecStart=/usr/bin/teleport start --pid-file=/run/teleport.pid --config teleport.yaml
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/teleport.pid
LimitNOFILE=8192

[Install]
WantedBy=multi-user.target

 10:20:50 ~
# systemctl status teleport.service
× teleport.service - Teleport SSH Service
     Loaded: loaded (/etc/systemd/system/teleport.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Tue 2023-10-24 10:20:37 UTC; 19s ago
   Duration: 144ms
    Process: 72198 ExecStart=/usr/bin/teleport start --pid-file=/run/teleport.pid --config teleport.yaml (code=exited, status=1/FAILURE)
   Main PID: 72198 (code=exited, status=1/FAILURE)
        CPU: 105ms

Oct 24 10:20:38 tokenomy-recovery teleport[72198]: ERROR: path 'teleport.yaml' does not exist
Oct 24 10:20:36 tokenomy-recovery systemd[1]: teleport.service: Failed with result 'exit-code'.
Oct 24 10:20:36 tokenomy-recovery systemd[1]: teleport.service: Scheduled restart job, restart counter is at 4.
Oct 24 10:20:36 tokenomy-recovery systemd[1]: Started Teleport SSH Service.
Oct 24 10:20:37 tokenomy-recovery systemd[1]: teleport.service: Main process exited, code=exited, status=1/FAILURE
Oct 24 10:20:37 tokenomy-recovery systemd[1]: teleport.service: Failed with result 'exit-code'.
Oct 24 10:20:37 tokenomy-recovery systemd[1]: teleport.service: Scheduled restart job, restart counter is at 5.
Oct 24 10:20:37 tokenomy-recovery systemd[1]: teleport.service: Start request repeated too quickly.
Oct 24 10:20:37 tokenomy-recovery systemd[1]: teleport.service: Failed with result 'exit-code'.
Oct 24 10:20:37 tokenomy-recovery systemd[1]: Failed to start Teleport SSH Service.

Some questionable service content are,

1) Description=Teleport SSH Service

On the server where teleport run as proxy/auth this should be "Teleport Proxy/Auth service".

2) WorkingDirectory=/etc/teleport

I never seen a service use /etc as working directory before. Usually working directory goes to /var, maybe /var/lib/teleport ? Also /etc/teleport directory does not get created by package installation, we need to create it manually.

3) LimitNOFILE=8192

Not sure what is the issue here. Why do we need to increase the limit?

4) ExecReload=/bin/kill -HUP $MAINPID

I don't think this is working as expected,

# ps -ef | grep teleport
root       72385       1  1 10:27 ?        00:00:00 /usr/bin/teleport start
root       72401   71989  0 10:27 pts/3    00:00:00 grep teleport

 10:27:47 ~
# kill -HUP 72385

 10:28:08 ~
# ps -ef | grep teleport
root       72419   71989  0 10:28 pts/3    00:00:00 grep teleport

# systemctl status teleport.service
○ teleport.service - Teleport SSH Service
     Loaded: loaded (/etc/systemd/system/teleport.service; enabled; preset: disabled)
     Active: inactive (dead) since Tue 2023-10-24 10:28:10 UTC; 1min 38s ago
   Duration: 36.363s
    Process: 72385 ExecStart=/usr/bin/teleport start (code=exited, status=0/SUCCESS)
   Main PID: 72385 (code=exited, status=0/SUCCESS)
        CPU: 604ms

Oct 24 10:28:10 tokenomy-recovery teleport[72404]: 2023-10-24T10:28:10Z WARN             Failed to resolve addr. error:[context canceled] reversetunnel/agentpool.go:743
Oct 24 10:28:10 tokenomy-recovery teleport[72404]: 2023-10-24T10:28:10Z WARN [PROXY:AGE] Agent pool exited. error:[
Oct 24 10:28:10 tokenomy-recovery teleport[72404]: ERROR REPORT:
Oct 24 10:28:10 tokenomy-recovery teleport[72404]: Original Error: *errors.errorString context canceled
Oct 24 10:28:10 tokenomy-recovery teleport[72404]: Stack Trace:
Oct 24 10:28:10 tokenomy-recovery teleport[72404]:         github.com/gravitational/teleport/lib/reversetunnel/agentpool.go:266 github.com/gravitational/teleport/lib/reversetunnel.(*AgentPool).run
Oct 24 10:28:10 tokenomy-recovery teleport[72404]:         github.com/gravitational/teleport/lib/reversetunnel/agentpool.go:253 github.com/gravitational/teleport/lib/reversetunnel.(*AgentPool).Start.func1
Oct 24 10:28:10 tokenomy-recovery teleport[72404]:         runtime/asm_amd64.s:1650 runtime.goexit
Oct 24 10:28:10 tokenomy-recovery teleport[72404]: User Message: context canceled] localCluster: targetCluster:tokenomy.internal reversetunnel/agentpool.go:254
Oct 24 10:28:10 tokenomy-recovery systemd[1]: teleport.service: Deactivated successfully.

@tukusejssirs Whoa, we are really getting into the details here, for further discussion I think we shouldn't be doing this on this packages' comments .. feel free to ping me on IRC or via mail tho!

The "resulting package" is the .tar.zst file, which stays the same for some changes to the PKGBUILD, like the one I made. In the end the combination of all these variables is used to determine whether there is an update to the package on a given system. The major/minor/patch variables are usually determined by the softwares upstream. So the usual case for a pkgrel bump (to my understanding) is something like this: Input source stays the same but a compilation flag is changed or a patch is applied so the output software delivered by the package is functionally different.

You can also think of it this way: A person that already has teleport-bin on their system reinstalls it uneccesarily, a person who does not have it yet gets the fix anyways.

But again: I also don't think that it would have been wrong to just bump pkgrel nonetheless, after all there are not thousands of users for this package, I just didnt do it ..

@christian-heusel, thanks for your explanation.

Maybe you’re right, but my understanding of the text in the docs is that it should be incremented whenever there is a change in the PKGBUILD file, regardless if the resulting program itself is the same. If the resulting program is different, that would mean that one of major/major/patch (or whatever versioning system the package uses) should be incremented.

I emphasise the bold part of the following citation from the docs, you emphasise the italics part of it. Either way, IMHO there should be no release with exactly the same version number which was already published (like in this case 12.1.1-1).

As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1.

Anyway, do as you wish, YMMV. :)

@tukusejssirs This change does not result in a different package after build, so I didn't bump pkgrel as per the wiki[0] (maybe thats nitpicky idk :P). This change will be included for the next regular release or if you pull this git repo.

Link [0]

Thanks, @christian-heusel! I didn’t want to suggest any more options than necessary, but I like your additions. ;)

However, shouldn’t you increment pkgrel when updating the package, but the package version stays the same?

@tukusejssirs Thanks for the suggestion! I impelemented it with a few more parameters to reflect the default in /etc/makepkg.conf.

Teleport download server does not support download resuming, therefore It might be a good idea to add -C0 option to curl in PKGBUILD. Otherwise, when downloading of the archive fails and we don’t clean-build the package next time, it will fail with curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume..

DLAGENTS=('https::/usr/bin/curl -C0 -o %o %u')

@r0zbot Added