turnkey-version could provide additional info

[JedMeister]

Currently turnkey-version can be quite useful for determining the version of TurnKey which the system was originally installed with.

---

Proposed switches/info:

• -f|--file=PATH/TO/FILE - read turnkey-version info from PATH/TO/FILE (defaults to /etc/turnkey_version if not set)
• -s|--string="TKL_VER_STR" - use TKL_VER_STR as turnkey-version (rather than reading from file); bonus points if it works with or without leading turnkey-.

Info derived from the turnkey-version file or string (as above); assuming turnkey-version (default behaviour) returns: turnkey-core-15.0-stretch-amd64

• -t|--tkl-appver - return space separate string of the 4 components - i.e. app-name tkl-version debian-codename architecture - e.g. core 15.0 stretch amd64.
• ... -

---

It would be useful if it also supported providing additional info (some items noted below end with '?' where unsure on whether or not they are a good idea...):

• the version of Debian (e.g. if it has been upgraded inline to a newer version of Debian, whilst still reporting an older version of TurnKey)
• the version of specific turnkey packages (e.g. tklbam, confconsole, etc).
• any turnkey packages which have available updates?
• the version of other specific packages (may help with troubleshooting? E.g. Apache, PHP, etc)?
• which apt repositories are enabled

Perhaps it could be somewhat modelled on the Proxmox pveversion commandline utility?

E.g. (on my home PVE server):

Basic output:

root@pve:~# pveversion 
pve-manager/4.3-14/3a8c61c7 (running kernel: 4.4.35-1-pve)

Complete output (i.e. verbose):

root@pve:~# pveversion -v
proxmox-ve: 4.3-75 (running kernel: 4.4.35-1-pve)
pve-manager: 4.3-14 (running version: 4.3-14/3a8c61c7)
pve-kernel-4.4.35-1-pve: 4.4.35-75
pve-kernel-4.4.19-1-pve: 4.4.19-66
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-48
qemu-server: 4.0-101
pve-firmware: 1.1-10
libpve-common-perl: 4.0-83
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-70
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-docs: 4.3-19
pve-qemu-kvm: 2.7.0-9
pve-container: 1.0-87
pve-firewall: 2.0-33
pve-ha-manager: 1.0-38
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.6-2
lxcfs: 2.0.5-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.8-pve13~bpo80

BTW, looks like I need to update! 😄

[Dude4Linux]

Excellent idea. In addition to the '-v' option, I'd like to suggest a '-j' option to return the same information in a .json format. This would make the turnkey_facts module in the Ansible appliance trivial.

Example of the current turnkey_facts output:
ansible@ansible ~/$ ansible localhost -m turnkey_facts localhost | SUCCESS => { "ansible_facts": { "turnkey": true, "turnkey_app": "ansible ", "turnkey_arch": "amd64", "turnkey_deb": "jessie", "turnkey_ver": "14.2", "turnkey_version_output": "turnkey-ansible-14.2-jessie-amd64" }, "changed": false }

[JedMeister]

I'm pinning this to the v15.0 milestone for now. I'm not sure if it'll happen or not, but it almost certainly won't if it's not on the milestone! 😄

[JedMeister]

WRT to turnkey-version, for v16.0 we have done some fairly significant refactoring. There's still more work required to realise the aim of this "issue", but it's something of a start...

We've updated turnkey-version to python3. We have also merged the turnkey-version tool into the turnkey-sysinfo package (which seemed like the logical first step in realising this increased functionality). TBH, (ended up un-merging packages again...) I doubt we'll get this done by the v16.0 release, but I'm really looking forward to having a bit more of a play with this at some point...

[JedMeister]

I'm going to update the OP with some more ideas re what this improved turnkey-version might provide...

[JedMeister]

WIP can be seen here: https://github.com/JedMeister/turnkey-version/tree/extra-functionality

[JedMeister]

The MVP of the discussion has been added via this PR: https://github.com/turnkeylinux/turnkey-version.

I'm going to unpin to milestones for now though as we're deep in "wishlist" territory to implement any more of the ideas.