Hi guys,
another app is ready for testing, Kimai is an open source time tracking software.
Installation is possible via Software Center by adding my repository, check https://repo.mrmarkuz.com for instructions.
The documentation is on GitHub.
Thanks in advance for testing and feedback!
Hi
Looks quite interesting, but some major questions.
It can’t handle bookkeeping but does billing?
Actually, there are plugins to integrate with other software, all pay per module…
Looks more and more like Odoo, where you end up paying lots of money for “open source”… 
My 2 cents
Andy
The background of creating this app is that a friend wants to migrate to NS8 and used Kimai in his company for time tracking.
The export plugin is free AFAIK but you are right, the better ones are paid modules.
If you are missing features, please be constructive and help me finding better time tracking software.
@mrmarkuz I have a list of time tracking software I was to. Implement, let. Me get home tonight and share the list. Then we could together identify which ones we can implement and which ones we can drop
Actually humongous for a time tracking tool (Which is actually not. Seems way bigger)
WHooT !!
But thanks!
Sorry guys, I’m going to try to find ways to optimize the used disk space.
If the container is that size am afraid the only solution is build your own.
Edit: seems kimai itself is only 256mb. So how does it end up requiring 20gig.
The image by Linuxserver is 126mb so would it maybe require 10gig instead of 20g
Let me check. I had the 20GB on a test node. On another test server it’s just 1,6GB.
1.6 makes sense, 20gig not so. Much.
Need to investigate why the other server required so much hdd
Odoo is atleast better and the upgrades not that alot if you consider. There is another one, let me try to remember, it’s worse. You can end up. Paying $1500 if you want all the plugins you require, and this is not even one off. It’s recurring
So much for “free” and OpenSource.
I consider Odoo and the “indian” fork of it pure crap - and also very slow…
I don’t see anything “better” about Odoo.
I was forced to use that crap in 2020 - also the fork… IMHO, both are crap.
My 2 cents
Andy
Even after reinstalling: On my Rocky server Kimai has 1,6 GB and on a Debian node it’s 23 GB. I’m still confused about that.
Rocky uses podman 4.6.1 whereas Debian has podman 4.3.1. On Debian extfs is the used file system, on Rocky it’s xfs.
[root@rocky1 ~]# podman info
host:
arch: amd64
buildahVersion: 1.31.3
cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- rdma
- misc
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.8-1.el9.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.8, commit: cebaba63f66de0e92cdc7e2a59f39c9208281158'
cpuUtilization:
idlePercent: 98.06
systemPercent: 0.55
userPercent: 1.4
cpus: 2
databaseBackend: boltdb
distribution:
distribution: '"rocky"'
version: "9.3"
eventLogger: journald
freeLocks: 2041
hostname: rocky1
idMappings:
gidmap: null
uidmap: null
kernel: 5.14.0-362.18.1.el9_3.x86_64
linkmode: dynamic
logDriver: journald
memFree: 480190464
memTotal: 8046632960
networkBackend: netavark
networkBackendInfo:
backend: netavark
dns:
package: aardvark-dns-1.7.0-1.el9.x86_64
path: /usr/libexec/podman/aardvark-dns
version: aardvark-dns 1.7.0
package: netavark-1.7.0-2.el9_3.x86_64
path: /usr/libexec/podman/netavark
version: netavark 1.7.0
ociRuntime:
name: crun
package: crun-1.8.7-1.el9.x86_64
path: /usr/bin/crun
version: |-
crun version 1.8.7
commit: 53a9996ce82d1ee818349bdcc64797a1fa0433c4
rundir: /run/user/0/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
pasta:
executable: ""
package: ""
version: ""
remoteSocket:
path: /run/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.1-1.el9.x86_64
version: |-
slirp4netns version 1.2.1
commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
libslirp: 4.4.0
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.2
swapFree: 6754410496
swapTotal: 8451518464
uptime: 271h 53m 11.00s (Approximately 11.29 days)
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- registry.access.redhat.com
- registry.redhat.io
- docker.io
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 3
paused: 0
running: 3
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mountopt: nodev,metacopy=on
graphRoot: /var/lib/containers/storage
graphRootAllocated: 75094818816
graphRootUsed: 3802759168
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "true"
imageCopyTmpDir: /var/tmp
imageStore:
number: 3
runRoot: /run/containers/storage
transientStore: false
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 4.6.1
Built: 1709719721
BuiltTime: Wed Mar 6 11:08:41 2024
GitCommit: ""
GoVersion: go1.20.12
Os: linux
OsArch: linux/amd64
Version: 4.6.1
root@contabo:~# podman info
host:
arch: amd64
buildahVersion: 1.28.2
cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- rdma
- misc
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon_2.1.6+ds1-1_amd64
path: /usr/bin/conmon
version: 'conmon version 2.1.6, commit: unknown'
cpuUtilization:
idlePercent: 97.15
systemPercent: 1.54
userPercent: 1.32
cpus: 4
distribution:
codename: bookworm
distribution: debian
version: "12"
eventLogger: journald
hostname: contabo
idMappings:
gidmap: null
uidmap: null
kernel: 6.1.0-20-amd64
linkmode: dynamic
logDriver: journald
memFree: 2455834624
memTotal: 8326475776
networkBackend: netavark
ociRuntime:
name: crun
package: crun_1.8.1-1+deb12u1_amd64
path: /usr/bin/crun
version: |-
crun version 1.8.1
commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
rundir: /run/user/0/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
path: /run/podman/podman.sock
security:
apparmorEnabled: true
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns_1.2.0-1_amd64
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.4
swapFree: 0
swapTotal: 0
uptime: 65h 24m 10.00s (Approximately 2.71 days)
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries: {}
store:
configFile: /usr/share/containers/storage.conf
containerStore:
number: 6
paused: 0
running: 6
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/lib/containers/storage
graphRootAllocated: 102974414848
graphRootUsed: 85116338176
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 128
runRoot: /run/containers/storage
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 4.3.1
Built: 0
BuiltTime: Thu Jan 1 01:00:00 1970
GitCommit: ""
GoVersion: go1.19.8
Os: linux
OsArch: linux/amd64
Version: 4.3.1
Might be possible that so much space is taken for different “behavior” of the underlying filesystem? IDK… Rocky allocates only the space needed, Debian use a “fat file” for something? Or that the version change introduced these kind of features?
Yeah, something like that. I think it’s about the way podman is able to store it’s overlay filesystem but I need to do some more reading and testing…
I discovered that last 4.x version of podman is 4.9. And 5.0 is a two-weeks newcome “stable” (ish… IMO)
Hi @mrmarkuz
In my experience, XFS is more performant than Ext4.
Debian runs well on XFS. NS7 also runs XFS…
Could be an issue point…
My 2 cents
Andy
Could you try installing another app both on
your debian and rocky instances then check the file sizes used.
Could someone else test these cases on rocky and debian, both for this app as well as other apps, and report if the same issue is experienced and if different case occurs, to share the information of their os setup?
It’s the same for all apps, on Debian they need more space.
I’m going to test some more like different os and filesystems…
The check by
du -hs /home/* | sort -hr
is much faster on Rocky.
EDIT:
I think it was a false alarm. The du command does not tell the truth in case of podman storage or includes cache or symlinks, IDK
When using podman system df the images have the same size on any system. Kimai has about 1,5 GB. I’m going to correct the first post…