Vista de Lectura

Hay nuevos artículos disponibles. Pincha para refrescar la página.

Guide: How to hide the nagging banners - Gitlab Edition

Guide: How to hide the nagging banners - Gitlab Edition

This is broken down into 2 parts. How I go about identifying what needs to be hidden, and how to actually hide them. I'll use Gitlab as an example.

At the time, I chose the Enterprise version instead of Community (serves me right) thinking I might want some premium feature way ahead in the future and I don't want potential migration headaches, but because it kept annoying me again and again to start a trial of the Ultimate version, I decided not to.

If you go into your repository settings, you will see a banner like this:

https://preview.redd.it/osbuuw08f62e1.png?width=1473&format=png&auto=webp&s=a4b215f66bcee42404affb4a3a485115c175c394

Looking at the CSS id for this widget in Inspect Element, I see promote_repository_features. So that must mean every other promotion widget also has similar names. So then I go into /opt/gitlab in the docker container and search for promote_repository_features and I find that I can simply do grep -r "id: 'promote" . which will basically give me these:

  • promote_service_desk
  • promote_advanced_search
  • promote_burndown_charts
  • promote_mr_features
  • promote_repository_features

Now all we need is a CSS style to hide these. I put this in a css file called custom.css.

#promote_service_desk, #promote_advanced_search, #promote_burndown_charts, #promote_mr_features, #promote_repository_features { display: none !important; } 

In the docker compose config, I add a mount to make my custom css file available in the container like this:

 volumes: - './custom.css:/opt/gitlab/embedded/service/gitlab-rails/public/assets/custom.css:ro' 

Now we need a way to actually make Gitlab use this file. We can configure it like this as an environment variable GITLAB_OMNIBUS_CONFIG in the docker compose file:

 environment: GITLAB_OMNIBUS_CONFIG: | gitlab_rails['custom_html_header_tags'] = '<link rel="stylesheet" href="/assets/custom.css">' 

And there we have it. Without changing anything in the Gitlab source or doing some ugly patching, we have our CSS file. Now the nagging banners are all gone!

https://preview.redd.it/6f85g018m62e1.png?width=1657&format=png&auto=webp&s=9a596ceececf4a6b54c64a79c9a4bdf4491e4237

Gitlab also has a GITLAB_POST_RECONFIGURE_SCRIPT variable that will let you run a script, so perhaps a better way would be to automatically identify new banner ids that they add and hide those as well. I've not gotten around that yet, but will update this post when I come to that.

Update #1: Optional script to generate the custom css.

import subprocess import sys CONTAINER_NAME = "gitlab" command = f""" docker compose exec {CONTAINER_NAME} grep -r "id: 'promote" /opt/gitlab | awk "match(\$0, / id: '([^']+)/, a) {{print a[1]}}" """ css_ids = [] try: css_ids = list(set(subprocess.check_output(command, stderr=subprocess.STDOUT, shell=True, text=True).split())) except subprocess.CalledProcessError as e: print(f"Unable to get promo ids") sys.exit(1) for css_id in css_ids[:-1]: print(f"#{css_id},") print(f"#{css_ids[-1]} {{\n display: none !important;\n}}") 
submitted by /u/sunshine-and-sorrow
[link] [comments]

Do you block outbound requests from your Docker containers?

Just a thought: I think we need a security flair in here as well.

So far I just use the official images I find on Docker Hub and build upon those, but sometimes a project has their own images which makes everything convenient.

I have been thinking what some of these images might do with internet access (Telemetry/Phone-home, etc.) and I'm now looking at monitoring and logging all outbound requests. Internet access doesn't seem necessary for most images, but the way the Docker network is set up, does actually have this capability.

I recently came across Stripe Smokescreen (https://github.com/stripe/smokescreen), which is a proxy for filtering outbound requests and I think it makes sense to only allow requests through this so I can have a list of approved domains it can connect to.

How do you manage this or is this not a concern at all?

submitted by /u/sunshine-and-sorrow
[link] [comments]

I'm gonna screw it all up. Well, sort-of but not exactly a disaster.

I have a MiniPC at home on which I run docker containers for the applications I need. Each application has backups, so all good here. I'm behind my ISP's CGNAT, so I have a VPS on which I run nginx and have it forward everything back to my home server via Wireguard. I have backups of my nginx config, so this is also fine.

So this is how things were for a while. Then I started adding more applications like Asterisk on-premise, which meant I had to do port forwarding from the VPS to my home address. I started maintaining a backup of my firewalld zones as well. Then I added ZNC as an IRC bouncer on the VPS itself. Over time I forgot what all I did on the VPS. There's firewall rules, there's modified systemd services (eg. I modify a service to run after another service has started), and I no longer have a track of everything due to my bad habit of doing everything directly on the server itself.

At the specific moment, I found it very convenient to just ssh in and do what I need without a second thought about whether I can replicate this again on a new server. In the event of a disaster, I can get everything set up from memory but it's gonna take a lot of time as I debug everything. Now I'm thinking I should've done everything as Ansible playbooks so everything is repeatable, but I can't help it because I just go in via ssh and do what I need.

How do you people deal with this? I feel like this is a workflow issue.

submitted by /u/sunshine-and-sorrow
[link] [comments]
❌