bisos.gitlab: GitLab CE via BISOS Capability Bundles (Dedicated VM; Base Code)
Overview
bisos.gitlab is a BISOS package for running GitLab CE from its Linux package as a BISOS Capability Bundle (CBS/CBM), browsable as http://gitlab.here.
It is base code for a dedicated VM, not yet run. GitLab is too large for a raw platform: its own baseline for one node is 8 vCPU and 16 GB of memory (8 GB as the stated minimum for memory-constrained setups), plus 40 GB of disk for the application, PostgreSQL and the repositories. Its CBM leaf is to be planted as available — visible, never brought up by a rawBisosCbm materialization (see bxGenesis/start/rawBisosCBMs/README.org). Everything here has been checked without installing GitLab (see “What Has and Has Not Been Checked”).
Package Documentation At Github
The information below is a subset of the full of documentation for this bisos-pip package. More complete documentation is available at: https://github.com/bisos-pip/gitlab-cs
Table of Contents TOC
Day-to-Day Admin: ``gitlabAdmin.cs` <#day-to-day-admin-gitlabadmincs>`__
-
First materialization, in a dedicated Debian 13 VM; record what it shows
Verify the packages.gitlab.com ``Release` signature with GitLab’s repository key <#verify-the-packagesgitlabcom-release-signature-with-gitlabs-repository-key>`__
The “secure it” layer: a real root password, HTTPS, listening beyond loopback
Plant the CBM leaf in brorawBisos as available (``sys/cbm/site/hereWeb/gitlab/` or collective) <#plant-the-cbm-leaf-in-bro_rawbisos-as-available-syscbmsiteherewebgitlab-or-collective>`__
How GitLab Fits the Pattern
bisos.gitlab follows the cbm-package-authorship pattern (one module of facts, gitlabInfo.py; a pinned, checksummed source; config written only when absent; a read-only driftCheck; server and usage sboms joined only by the CBS) with three differences, all from how GitLab’s Linux package works:
GitLab runs its own platform. The package brings PostgreSQL, Redis, Puma, Sidekiq, Gitaly and workhorse, supervised by runit under one systemd unit of its own, gitlab-runsvdir.service. bisos.gitlab therefore declares no systemd unit: its CBS’s unit list is empty.
Configuration is ``gitlab.rb`` plus ``gitlab-ctl reconfigure`` (a Chef run). The sbom writes /etc/gitlab/gitlab.rb before installing the package — which creates one only when it is absent — and runs reconfigure after it.
BISOS’s nginx is the front. The bundled nginx is disabled; workhorse listens on TCP loopback, 127.0.0.1:24016 (banna’s gitlab port), and gitlab-wvd.pcs proxies gitlab.here to it.
gitlab.rb also sets the memory-constrained settings of GitLab’s own guide (Puma with no worker processes, Sidekiq concurrency 10, bundled monitoring off, faster memory release) and turns the usage ping off.
The Login
GitLab’s administrator is root, and GitLab refuses passwords shorter than 8 characters, so the rawBisos convention (user admin, password the service’s name) cannot apply as is. The initial password is rawBisos-gitlab: set in gitlab.rb, applied once when the database is created. Insecure by design; securing a host is a separate layer on top.
What Gets Installed, and Where
What |
Where |
Owner |
|---|---|---|
GitLab’s five accounts |
uid/gid 520–524, banna |
— |
GitLab CE 19.5.0 (the package) |
/opt/gitlab (about 4.2 GB) |
root |
Its configuration |
/e tc/gitlab/gitlab.rb |
root 600 |
Its data (DB, repositories) |
/var/opt/gitlab |
GitLab’s accounts |
Its logs |
/var/log/gitlab |
GitLab’s accounts |
glab 1.123.0 (usage side) |
/opt/gl ab/current/bin/glab |
root |
The accounts are git (520, shell /bin/sh for git over ssh), gitlab-www (521), gitlab-redis (522), gitlab-psql (523), gitlab-prometheus (524): the gitlab block of bisos.banna.sysAccts. The sbom creates them first, so banna’s check (refuse a number held by someone else) applies, and gitlab.rb gives GitLab the same numbers.
The package is pinned as gitlab-ce_19.5.0-ce.0_amd64.deb for Debian 13 (trixie), with the SHA-256 from packages.gitlab.com’s trixie index (that index matches the repository’s Release file; the Release signature was not verified). GitLab builds a package per Debian release, so the sbom refuses another release or architecture. Its download path carries the release (pool/trixie/main/...); the index’s Filename (pool/main/...) returns 404.
The 3 sboms
sbom |
Installs |
Pulls in |
|---|---|---|
gitlab-sbom.pcs |
accounts, gitlab.rb, the package, reconfigure |
nothing |
gitlabUsage-sbom.pcs |
glab, GitLab’s CLI (small; fine on any raw platform) |
nothing |
gitlabCbs-sbom.pcs |
nothing of its own |
both |
What Has and Has Not Been Checked
Checked on a raw platform without GitLab (2026-10-16):
Every planted file’s menu and readme; both sboms’ package lists; the bundle lists both sboms.
The generated gitlab.rb passes ruby -c; the vhost passes nginx -t; every bash script passes bash -n; pyflakes clean; py3/tests/verify.sh passes.
The package URL answers (a ranged request) and redirects to a storage object named by the pinned SHA-256; glab’s tarball was downloaded and matched its published SHA-256.
Not run anywhere yet: installing the package, gitlab-ctl reconfigure with this gitlab.rb (including GitLab accepting the banna uids, workhorse on TCP and the root password), the vhost in front of workhorse, gitlabAdmin.cs against a live GitLab, cbs_materialize, the CBM leaf.
Materializing in a Dedicated VM
On a Debian 13 BISOS VM with at least 8 GB of memory (16 GB recommended) and 40 GB of free disk:
pip install -e /bisos/git/bxRepos/bisos-pip/gitlab/py3 # or pipx install bisos.gitlab
gitlab-cbs.pcs -i cbs_materialize # accounts, gitlab.rb, package, reconfigure; dns, vhost
gitlabAdmin.cs -i driftCheck # gitlab.rb, package version, account numbers
sudo gitlab-rake gitlab:check SANITIZE=true
curl -s http://127.0.0.1:24016/-/health
Then browse http://gitlab.here and log in as root / rawBisos-gitlab. The first reconfigure takes several minutes, and nginx answers 502 until workhorse is up.
Day-to-Day Admin: gitlabAdmin.cs
gitlabAdmin.cs -i hostInfo # fqdn, workhorse port, root login, GitLab's paths
gitlabAdmin.cs -i servicesInfo # gitlab-ctl status/restart/tail/reconfigure; dns and vhost
gitlabAdmin.cs -i checksInfo # gitlab-rake gitlab:check, env:info; health endpoints
gitlabAdmin.cs -i driftCheck # read-only: gitlab.rb, package version, account numbers
quickGitlab.cs # the flat cheat sheet
Key Files
py3/bisos/gitlab/gitlabInfo.py — the single source of facts: the pinned package and glab, the accounts, paths, port, login, the gitlab.rb generator and the install scripts.
py3/bin/gitlab-cbs.pcs, cbmProc-gitlab.spcs — the CBS (no units) and the CBM pointer.
py3/bin/gitlab-sbom.pcs, gitlabUsage-sbom.pcs, gitlabCbs-sbom.pcs — the three sboms.
py3/bin/gitlab-assemble.cs, gitlab-here-dns.pcs, gitlab-wvd.pcs — assembly: dns and vhost.
py3/bin/gitlabAdmin.cs, quickGitlab.cs — admin CS and cheat sheet.
py3/tests/verify.sh — smoke test and gitlabInfo invariants; runs without GitLab.
Part of BISOS — ByStar Internet Services Operating System
Layered on top of Debian, BISOS (By* Internet Services Operating System) is a unified and universal framework for developing both internet services and software-service continuums that use internet services. See Bootstrapping ByStar, BISOS and Blee for getting started with BISOS.
BISOS is a foundation for The Libre-Halaal ByStar Digital Ecosystem which is described as a cure for losses of autonomy and privacy in a book titled: Nature of Polyexistentials
bisos.gitlab is part of BISOS. It is a standalone package that can be used independently of the full BISOS environment.
Documentation and Blee-Panels
bisos.gitlab is part of the ByStar Digital Ecosystem http://www.by-star.net. Its primary documentation is in the form of Blee-Panels, in ./panels; see file:./panels/bisos.gitlab/_nodeBase_/fullUsagePanel-en.org for a starting point. It is best developed with Blee, the By* BISOS Libre-Halaal Emacs Environment.
Support
Planned Improvements
TODO First materialization, in a dedicated Debian 13 VM; record what it shows
TODO Verify the packages.gitlab.com Release signature with GitLab’s repository key
TODO The “secure it” layer: a real root password, HTTPS, listening beyond loopback
TODO Plant the CBM leaf in brorawBisos as available (sys/cbm/site/hereWeb/gitlab/ or collective)
Metadata
Release files for bisos.gitlab 0.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| bisos_gitlab-0.1.tar.gz | 45.8 kB | Without provenance | Details for bisos_gitlab-0.1.tar.gz |
Release files / bisos_gitlab-0.1.tar.gz
| Download URL | bisos_gitlab-0.1.tar.gz |
|---|---|
| Size | 45.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3c6a005379060f89669910c175cc1f0a8db0696d724a26e7865c1cb44d26ea2b
|
|
BLAKE2b-256 checksum How to use checksums |
6e2dbadbcbb885314da2afb1ef96d841d2c8fcc33481e8322c4a2ef909f1cdd4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.11.2
|
Security for bisos.gitlab 0.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.