Coder Legion - Recent posts tagged configuration

How to Prepare WAF Environment Variables for a Manual Deploy

Mon, 02 Nov 2026 02:55:20 +0000

A manual SafeLine deploy is not finished when .env merely contains every key from the sample. The install guide shows a template, then a separate secret-generation section. Stopping after the paste leaves instructions where passwords and tokens must be. That is the misconfiguration this note isolates, together with the screens that confirm it is gone.

What manual preparation actually includes

SafeLine is a self-hosted web application firewall. Deployed in front of a web application, it acts as a reverse proxy: clients reach the WAF first, and the WAF filters, monitors, and blocks malicious HTTP/S traffic before forwarding the rest. The product documentation lists defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home).

The deploy guide recommends an automatic installer, then documents a manual path for operators who prepare the host themselves. Manual preparation has a fixed order: install Docker if needed, create /data/safeline with at least 5 GB free, download compose.yaml, write .env, generate secrets, lock permissions, create resource directories, then run docker compose up -d (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

Check the host before touching variables. The documented minimums are Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, 1 CPU core, 1 GB of memory, 5 GB of disk, and a CPU with ssse3. The guide's own checks are uname -m, docker version, docker compose version, cat /proc/cpuinfo | grep "processor", free -h, df -h, and lscpu | grep ssse3.

One misconfiguration: placeholders left in the environment file

The concrete mistake is writing the sample block and treating the bracketed fields as finished values. The deploy guide's .env example includes:

POSTGRES_PASSWORD={postgres-password}
DETECTOR_MGMT_TOKEN=<64-char hex>
MGT_INTERNAL_TOKEN=<64-char hex>
DETECTOR_AES_KEY=<16 alphanumeric characters>

Those strings are fill-in markers. {postgres-password} is not a database password. <64-char hex> is not a token. <16 alphanumeric characters> is not an AES key. A file that still contains those markers has not completed the "Write Environment variables" step, even if SAFELINE_DIR, IMAGE_TAG, MGT_PORT, SUBNET_PREFIX, IMAGE_PREFIX, REGION, MGT_PROXY, DETECTOR_MGMT_AUTH, and DETECTOR_UPDATE_VERIFY were copied correctly.

The same example leaves DETECTOR_UPDATE_PUBLIC_KEY empty. Do not invent a public key, a default Postgres password, or a shared token. The guide does not provide those values.

It also does not publish a dedicated error line for this mistake. Do not promote an unrelated container message into proof. Proof is a reread of .env, then the two success screens the install guide does document.

Replace only the fields the guide tells you to generate

From the SafeLine directory, generate the three secrets with the documented commands and write them through set_env, which replaces an existing key instead of appending a duplicate.

DETECTOR_MGMT_TOKEN comes from od -An -N32 -tx1 /dev/urandom with spaces and newlines removed. Thirty-two bytes of hex are 64 hexadecimal characters. MGT_INTERNAL_TOKEN uses the same command in a separate run. Do not copy one token into the other variable.

DETECTOR_AES_KEY comes from LC_ALL=C tr -dc 'A-Za-z0-9' </dev/urandom | head -c 16. It must be 16 letters or digits. A shorter cut, a value with punctuation, or the angle-bracket marker is still the original misconfiguration.

Set POSTGRES_PASSWORD to a real initialization password you choose and store. The guide defines that variable as the Postgres database initialization password. It does not publish a default.

Leave the other sample values in place unless a documented case applies:

IMAGE_TAG is the SafeLine version to use. The sample is latest.
MGT_PORT is the web console port. The sample is 9443, and the documented console URL uses that port.
SUBNET_PREFIX is the internal network address prefix. The sample is 172.22.222.
IMAGE_PREFIX is the mirror repository prefix. The sample is chaitin.
REGION is shown as -g.
MGT_PROXY is the number of console proxy layers. The guide says to use it only when configuring a proxy for the console. The default is 0, which means no proxy is configured. Raising it on a direct console is a different mistake. It does not fix missing secrets.
DETECTOR_MGMT_AUTH=on and DETECTOR_UPDATE_VERIFY=on stay as shown.
POSTGRES_IMAGE in the x86_64 sample is chaitin/safeline-postgres:15.18.

On ARM, change two lines together: ARCH_SUFFIX=-arm and POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18. The deploy guide states that SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. An empty ARCH_SUFFIX on arm64 is a second pre-flight fault, not a substitute for generated secrets.

For the LTS channel, set RELEASE=-lts. The guide states that the LTS version will no longer be maintained starting from 9.1.0-LTS (14 August 2025), and that LTS users are strongly recommended to upgrade to the latest version. If you have concerns, it recommends upgrading one month after a new release. Leave RELEASE empty when you want the sample latest channel.

After set_env writes the three generated values, run chmod 600 .env. The guide repeats that mode in the new-install directory steps, along with chmod 700 on the run, mgt, sock, and postgres data paths, and a symlink from /data/safeline/resources/run/safeline.sock to /var/run/safeline.sock.

Read the file before docker compose up -d. Both tokens should be 64 hex characters with no spaces. The AES key should be 16 alphanumeric characters. The Postgres password should not contain braces. MGT_PROXY should remain 0 unless console proxy layers are actually in use. On ARM, the suffix and the ARM Postgres image must match.

The screen that confirms the fix

Start from /data/safeline with docker compose up -d. The guide says this process may take several minutes.

Open https://<safeline-ip>:9443/ when MGT_PORT is still 9443. The deploy guide says the web console page is what you see. If you changed MGT_PORT, open the port written in .env, not a remembered default. That console page is the first documented confirmation that the manual start reached the management UI.

Then run docker exec safeline-mgt resetadmin. The guide says a successful run tells you to remember the content, then prints the initial username admin, an initial password, and Done. That account text is the second confirmation. Store it. It does not appear in .env, and the guide does not tell you to paste it back into the environment file.

Log in with that password. Site protection is a later console step, not an environment-variable step. The application guide says to open Applications, choose Add Application, set Domain, Port, and Upstream, then resolve the domain to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A working login only shows that the console account was issued.

If the console page does not appear, return to .env before changing unrelated settings. Confirm the four replaced fields, mode 600, the architecture pair, and MGT_PROXY. The install guide's confirmation path is the console page plus the resetadmin account text. It is not an undocumented log phrase.

Why does the sample contain values I must not keep?

The deploy guide prints a full .env example so the key names exist, then adds secret generation. The brace and angle-bracket strings mark fields to replace. A visual match to the example is not the same as a finished file.

How long are the two management tokens?

Each documented generator reads 32 bytes with od -An -N32 -tx1 and strips spaces and newlines. That is 64 hexadecimal characters for DETECTOR_MGMT_TOKEN and another 64 for MGT_INTERNAL_TOKEN. Generate them separately.

What is a valid DETECTOR_AES_KEY?

Sixteen characters from A-Z, a-z, and 0-9, produced by the guide's tr and head -c 16 command. Punctuation, spaces, and the angle-bracket placeholder are not valid stand-ins.

Should MGT_PROXY change for a console on port 9443?

No. MGT_PROXY counts console proxy layers and stays 0 when no proxy is configured. The console address is https://<safeline-ip>:9443/ while MGT_PORT remains 9443.

Which screen shows the environment file is fixed?

Two documented results. The browser shows the web console at the host and port from the install, by default https://<safeline-ip>:9443/. Then docker exec safeline-mgt resetadmin prints the initial username admin, an initial password, and Done. If either result is missing, recheck placeholders, token length, AES key length, mode 600, and the ARM image pair before assuming a different fault.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why I Finish the Environment File Before Turning Protection On

Mon, 02 Nov 2026 02:54:48 +0000

I do not turn SafeLine protection on the moment the containers start. Protection, in the sense that matters to an application, begins when traffic is sent through the WAF and an application is added in the console. Before that cutover I want a written decision on every environment variable the manual deploy expects. A half-filled .env file is not a minor cleanup task. It is the file that sets the install directory, the image tag, the console port, the database password, the internal network prefix, and the secrets the detector and management services share.

SafeLine is a self-hosted web application firewall. The introduction describes it as a reverse proxy placed in front of a web application. Clients pass through that proxy before they reach the origin. It filters and monitors HTTP and HTTPS traffic and is documented to block malicious requests such as SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. The same introduction lists core capabilities that include defenses for web attacks, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. Feature notes also describe rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection for HTML and JavaScript. Those controls are only useful after the proxy path is correct, so I treat the environment file as the last gate before I point a domain at the WAF. Source: https://docs.waf.chaitin.com/en/home

The decision I make before any traffic moves

The application guide says SafeLine is developed based on nginx. It receives traffic for the original site, cleans malicious attack traffic, and forwards the remaining traffic to the upstream application. Adding an application in the console requires a domain, hostname, or IP, a listen port such as 80 or 443, and the real upstream address. For HTTPS applications the SSL option must be checked. After those fields are saved, the domain has to resolve to the SafeLine server. That DNS change is the moment protection becomes real for users. I will not make it until the manual deploy variables are decided, written, and permission-locked. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Manual deploy is documented separately from the automatic installer. It expects Docker, a directory with at least 5 GB free, a downloaded compose file, and a .env file that you write yourself. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Checklist before I write the file

I run the host checks from the deploy guide before I choose any value. The documented minimums are Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, one CPU core, 1 GB of memory, 5 GB of disk, and a CPU with the ssse3 instruction. The same page lists the commands I actually run: uname -m, docker version, docker compose version, a processor listing from /proc/cpuinfo, free -h, df -h, and lscpu piped to a search for ssse3. If any of those checks fail, I stop. I do not plan to turn protection on against an undersized or unsupported host and fix the platform later.

Then I decide the variables in the official template, not a shortened list of my own.

Directory and image choices come first. SAFELINE_DIR is the directory SafeLine uses for configuration and data. The guide creates /data/safeline and requires at least 5 GB there. IMAGE_TAG is the SafeLine version to be used. I keep latest only when I have already accepted that channel. IMAGE_PREFIX is the mirror repository prefix. The template sets it to chaitin, and I keep that published value rather than inventing another registry path.

The release channel is a separate decision. Setting RELEASE=-lts selects the LTS images. The deploy page states that the LTS version will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and that LTS users are strongly recommended to upgrade to the latest version. If concerns remain, the same note recommends upgrading one month after a new version is released. An empty RELEASE is also a decision: it means I am not selecting the LTS suffix. I write that choice down before I touch the file.

Architecture is not optional on ARM. For an ARM server the guide says to set ARCH_SUFFIX=-arm and to set POSTGRES_IMAGE to chaitin/safeline-postgres-arm:15.18. On the default template, ARCH_SUFFIX is empty and POSTGRES_IMAGE is chaitin/safeline-postgres:15.18. The same section states that SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. If I cannot accept that boundary, I do not continue an ARM manual deploy, and I do not swap in the non-ARM image names to avoid the decision.

Network and console choices are next. MGT_PORT is the web console port. The template and the later UI step both use 9443, and the console URL is https:// followed by the SafeLine IP, port 9443, and a trailing slash. I change that port only after I have checked that the host can spare it, and I record the chosen port in the access plan before launch. SUBNET_PREFIX is the internal network communication address prefix. The template uses 172.22.222. I compare that prefix with existing Docker and host networks before I keep it. MGT_PROXY is the number of console proxy layers. The guide says it should be used only when configuring a proxy for the console, and that the default of 0 means no proxy is configured. I leave it at 0 unless that console-proxy case is actually mine. The template also includes REGION=-g. The variable glossary on the same page does not define REGION, so I keep the documented example instead of guessing another region code.

Secrets are generated, not typed from memory. The guide shows three commands run from the SafeLine directory. DETECTOR_MGMT_TOKEN and MGT_INTERNAL_TOKEN each come from 32 random bytes printed as hexadecimal, which matches the template note of a 64-character hex value. DETECTOR_AES_KEY is 16 alphanumeric characters drawn from /dev/urandom. POSTGRES_PASSWORD is the Postgres database initialization password, so I replace the placeholder before the first start. The template also sets DETECTOR_MGMT_AUTH=on and DETECTOR_UPDATE_VERIFY=on, and it leaves DETECTOR_UPDATE_PUBLIC_KEY empty. I copy those lines as published. I do not fill the public-key field with a value the deploy page does not specify. A small set_env helper in the same section updates an existing key or appends it, which is how I avoid leaving a placeholder beside a generated value.

How I commit the file without turning protection on

After the decisions are written down, I create /data/safeline, download the compose file into that directory, and write .env. I then set the file mode to 600. The later directory steps also create the runtime path, set the runtime, management, socket, and Postgres data directories to mode 700, set .env to mode 600 again, and link the runtime socket file to /var/run/safeline.sock. Those permission steps are part of the checklist, not optional cleanup after the first request.

Only then do I run docker compose up -d. The guide says this can take several minutes. A running stack is still not protection. I open the console on the port I chose, run docker exec safeline-mgt resetadmin, and store the initial admin username and password that command prints. I log in and confirm the console is the one I intended. I still do not add an application, and I do not change DNS, until every checklist item above is marked done. Adding the application, resolving the domain to the SafeLine host, and sending traffic are the steps that place the reverse proxy in the user path. That is the turn-on I am trying not to rush.

What I refuse to skip

I keep the checklist short enough to finish on the day of the deploy, and strict enough that a missing secret or an undecided ARM license stops the work. The answers I want in writing are the architecture and image names, the release channel, the directory and disk budget, the console port and proxy-layer count, the subnet prefix, and the generated secrets with their file mode. If one answer is that the team will fix it after go-live, I do not add the application.

Why do I separate container start from turning protection on?

Container start only brings up the SafeLine services described in the deploy guide. Protection for a site starts when I add an application and resolve its domain to the SafeLine server, as the application guide describes. I want the environment file finished before that DNS and upstream cutover, because a wrong port, subnet, architecture suffix, or secret is much harder to explain once users are already flowing through the proxy.

Which variables do I refuse to leave as placeholders?

I replace the Postgres password, the detector management token, the management internal token, and the detector AES key before the first docker compose up -d. The deploy page shows those as generated or chosen values, not as text to leave in the file. I also decide ARCH_SUFFIX, POSTGRES_IMAGE, and RELEASE explicitly, including the decision to leave RELEASE empty when I am not selecting LTS.

What host facts can block the whole checklist?

The deploy requirements can block the work before any variable is written. I need Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, at least one core, 1 GB of memory, 5 GB of disk, and ssse3. On ARM I also need to accept that a Pro license is required and that the Personal Edition is not supported. If those facts are not true, I do not continue to the console or to an application entry.

Should I change MGT_PROXY or REGION while preparing the file?

I set MGT_PROXY to 0 unless I am actually configuring proxy layers for the console, which is the only case the deploy guide describes. I keep REGION=-g because that is the value in the published template, and the variable list does not give me another documented choice. Guessing either value is not part of preparing the file.

What do I do with the admin password relative to this checklist?

After compose is up, docker exec safeline-mgt resetadmin prints the initial username and password. I treat that output as a secret to store before anyone else uses the console. It is not a substitute for the .env secrets. Both have to be known and restricted before I add an application and call the site protected.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Copilot CLI Model Settings

Thu, 29 Oct 2026 21:03:27 +0000

When working with GitHub Copilot, you may encounter a situation where the selected model changes unexpectedly when moving between different repositories or invocation surfaces. Understanding why this happens requires inspecting your installed CLI version, session state, explicit flags, environment variables, user settings, repository settings, and managed policies before modifying your configuration.

Quick solution:
To inspect your active model selection and configuration directories, run the following diagnostic command in your terminal:

github-copilot-cli --help

For deeper official documentation, consult the Copilot CLI programmatic model configuration and Copilot CLI configuration directory guides.

Introduction to Copilot CLI Model Settings

The Copilot CLI model settings are typically configured using a JSON file located in your local configuration directory. However, these settings can be dynamically overridden by various runtime layers. To properly manage your environment, you must account for the following precedence factors:

Installed CLI version: Minor and major version differences across machines or container environments can alter default fallback models.
Session state: Active custom agents or resumed chat sessions may retain model bindings from their initial instantiation.
Explicit flags: Command-line flags passed directly during execution take immediate precedence over stored files.
Environment variables: Shell or CI pipeline variables can silently override persistent file configurations.
User and repository settings: Local overrides defined within specific projects can diverge from your global user preferences.
Managed policies: Enterprise or organizational guardrails can enforce specific models regardless of local developer intent.

Configuring Copilot CLI Model Settings

To establish a baseline configuration, create or edit your local settings file to specify your preferred model explicitly. Maintaining a clear JSON structure ensures predictable behavior across different workflows.

{
  "model": "gpt-4o"
}

When managing complex environments or multiple developer workflows, ensuring your project files remain clean is critical. For broader insights into maintaining agent configurations, many developers also reference guides such as Configuring Mcp Json Files For Ai to align their local setups.

Understanding Override Precedence

When debugging why a model switched without your direct input, evaluate the hierarchy of configuration layers. The execution engine resolves settings in the following strict order from highest to lowest precedence:

Explicit command-line flags
Active environment variables (such as runtime overrides)
Repository-level configuration files
Global user-level settings files
Enterprise managed policies
Built-in default model settings

If a repository contains a local configuration file, it will override your global user settings whenever you execute commands from within that directory. This explains why a model selection appears correct in one project but reverts or changes in another.

Verifying Copilot CLI Model Settings

To confirm which model is currently active without executing token-heavy prompts or logging sensitive data, inspect the local runtime output and help flags. Checking the installed help output reveals active runtime defaults and helps isolate whether an environment variable is actively masking your JSON configuration file.

Troubleshooting Model Drift Across Repositories

When model drift occurs between projects, work through this systematic troubleshooting workflow:

Inspect local directory contents for hidden .github or configuration files that might contain repository-specific model overrides.
Print active environment variables in your current terminal session to check for lingering override strings.
Compare the behavior of a fresh CLI session against a resumed historical session.
Validate that your JSON syntax adheres strictly to expected schema requirements without trailing commas or mismatched brackets.

Verification Checklist

Verify that your JSON configuration file is correctly formatted and placed in the appropriate directory.
Check your active terminal environment variables for conflicting override parameters.
Run the installed help command to inspect active overrides in your current environment.
Test your configuration inside a clean repository directory to ensure consistent model selection.

How to Configure and Control Nginx?

Tue, 21 Apr 2026 02:19:50 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In previous article I explinaed how nginx works and what is the architecture of nginx.

Now let's configure it and controls nginx.

Understanding Nginx Controls

Reload

nginx -s reload

This signal is used to reload the configuration files of nginx.
It will not stop the nginx processes.
It will just reload the configuration files and start the new worker processes.
If old worker process serving few clients it will be served by old worker process.

Either master will stop old worker process or it will wait for the old worker process to finish serving the current requests.

This way if anything has issues nginx will not apply new configuration files.

Quit

nginx -s quit

This signal is used to quit the nginx processes.

It will stop the nginx processes and wait for the worker processes to finish serving the current requests.

Stop

nginx -s stop

This signal is used to stop the nginx processes.

It will stop the nginx processes and wait for the worker processes to finish serving the current requests.

To stop nginx with PID. We can use kill command.

kill -QUIT <master_pid>

We can also find all PID

ps -ax | grep nginx

Configure Nginx

nginx consists of modules which are controlled by directives specified in the configuration file.

These Directives are divided into simple directives and block directives.

Similar to C language, simple directive consists of the name and parameters separated by spaces and ends with a semicolon (;).

A block directive has the same structure as a simple directive, but instead of the semicolon it ends with a set of additional instructions surrounded by braces ({ and }).

If a block directive can have other directives inside braces, it is called a context (examples: events, http, server, and location).

Directives placed in the configuration file outside of any contexts are considered to be in the main context. The events and http directives reside in the main context, server in http, and location in server.

The rest of a line after the # sign is considered a comment.

Here is the simple example of nginx configuration file:

Main context: worker_processes 1;

events context: worker_connections 1024;

http context: we define server context here.

server context: In here we define this to listen port 80 which is http port.

location context: In here we define the root directory of the website.

So, any request coming to port 80 will be served by the worker process with the root directory of /var/www/html.

# This is a comment in the Main Context
worker_processes 1; 

events { 
    # This is a simple directive inside the 'events' context
    worker_connections 1024; 
}

http { 
    # We are now inside the 'http' context

    server { 
        # The 'server' context is nested inside 'http'
        listen 80; 

        location / { 
            # The 'location' context is nested inside 'server'
            root /var/www/html; 
        }
    }
}

Conclusion

We understood how to control nginx and how to configure nginx.

So, this makes solid foundation for us to understand how work with nginx.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Why is Nginx configuration organized as sites-available and sites-enabled?

Thu, 16 Apr 2026 23:34:22 +0000

In this article, We will exploring how to do nginx configuration directory structure. Why it is organized in this way?

How are ngix config files organized?

Majorly nginx config files are organized in the following way:

Main config file: /etc/nginx/nginx.conf This deal with setting up global configuration for nginx.
Sites available directory: /etc/nginx/sites-available This deal with setting up sites configuration for nginx. Where we can write multiple site configuration files.
Sites enabled directory: /etc/nginx/sites-enabled This deal with enabling sites configuration for nginx. Where we can enable sites configuration.
Logs directory: /var/log/nginx This deal with logs configuration for nginx. Where we can see logs of nginx.
Cache directory: /var/cache/nginx This deal with cache configuration for nginx. Where we can see cache of nginx.

How to write site configuration file?

A site configuration file is a file that is used to configure a site for nginx.

Which you can further read in official documentation https://nginx.org/en/docs/.

These configuration should be written in this directory.

/etc/nginx/sites-available

Once you write the configuration file. This will not enable the site.

How to enable the site?

To enable the site, you need to create a symbolic link from the sites-available directory to the sites-enabled directory.

For example, if you have a site configuration file named example.com in the sites-available directory, you can enable it by running the following command:

we should always test the configuration file before enabling it.

sudo nginx -t

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com

This will create a symbolic link from the sites-available directory to the sites-enabled directory.

The core reason for using symbolic link is that it will allow us to enable and disable the site without removing the configuration file.

if we directly put the configuration file in sites-enabled directory, then we need to remove the configuration file to disable the site.

That means if I want to update small change.
If the configration was copy to sites-enabled directory, then on nginx server restart, the changes will not be reflected.

so, to make it easier we use symbolic link.

Now once the site is enabled, we need to restart the nginx server to apply the changes.

sudo systemctl restart nginx

Finaly we can access the site in browser.

How to disable the site?

To disable the site, you need to remove the symbolic link from the sites-enabled directory.

sudo rm /etc/nginx/sites-enabled/example.com

By this process it will not delete the configuration file. We can enable and disable the site without removing the configuration file.

Conclusion

By this we understood how to enable and disable the site in nginx.

How configuration file is organized in nginx.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Loosely coupled configuration for Home Assistant

Thu, 17 Jul 2025 19:22:03 +0000

This post will be short, but I hope it prove to be useful.

My home is getting more and more connected, and the number of my automations grows each passing month. Recently, I equipped my roller shutters with connected Somfy engines so they could roll down automatically when it's too hot in summer. Spoiler: given the current heatwave, it's a boon!

I naively created the following automation configuration:

- id: '1742926520608'
  alias: Close all shutters
  description: Close all shutters if it's already hot in the morning
  triggers:
  - trigger: time                                                      #1
    at: 07:00:00
  conditions:
  - condition: numeric_state
    entity_id: sensor.saint_julien_en_genevois_temperature
    above: 23                                                          #2
  actions:
  - action: cover.close_cover                                          #3
    metadata: {}
    data: {}
    target:
      entity_id: cover.all_shutters                                    #4
  mode: single

If at 7 AM local time
The temperature where I live is higher than 23°C
Close
All shutters

Note the entity ID cover.all_shutters: it's not an out-of-the-box entity. I explicitly created a group for it:

cover:
  - platform: group
    name: "All shutters"
    entities:
      - cover.left_shutter
      - cover.middle_shutter
      - cover.right_shutter
      - cover.bedroom_shutter
      - cover.office_shutter

I copied the same approach to switch all the lights off when I leave home. I soon realized there were flaws in this approach.

While the probability of adding more shutters is pretty low, I'll likely add more smart lights in the future. Every time I add one, I'll need to put it in the group. Also, I added lights in waves; I ID'd the lights in French at first, but later switched to English. As I renamed them all in English to be coherent, I had to update my dashboard to adapt to the new IDs.

Home Assistant already has everything to cater for the above, Areas. You can–and you probably should-assign every device to an Area. Once done, you can replace the target part of the automation with a list of area_id instead of entity_id.

- id: '1742926520608'
  alias: Close all shutters
  description: Close all shutters if it's already hot in the morning
  triggers:
  - trigger: time
    at: 07:00:00
  conditions:
  - condition: numeric_state
    entity_id: sensor.saint_julien_en_genevois_temperature
    above: 23
  actions:
  - action: cover.close_cover
    metadata: {}
    data: {}
    target:
      area_id:                                                         #1
        - office
        - bedroom
        - living_room
  mode: single

Now, Home Assistant closes all shutters that are in any of these areas

Areas tend to be much more stable than individual devices. How often do you add a new area to your home? Granted, an area doesn't explicitly map to a room, but I think that's a better approach than my original one. Home Assistant will now manage every new device of the same type added to the area, e.g., if you motorize a new shutter or add a new light.

There's one drawback to this approach. UI Tiles accept only a single entity ID. Thus, if you want to use the GUI, you must create a group as I did in my first approach.

In this post, I showed how you could replace the explicit grouping of devices by areas. It's the same idea of loose coupling we have in software, but applied to Home Assistant configuration.

To go further:

Originally published at A Java Geek on July 13^th, 2025