you can create secrets on a easy way.

$ echo "secretdata" > secretfile.txt
$ podman secret create secretname secretfile.txt
e17465c9772b38f336fc4cbac

you can use the created secret easy, too

$ podman run --secret secretname --name foo alpine cat /run/secrets/secretname secretdata

actually there are only 2 ways to use this secrets.

1. from local environment variable to container, as file
2. from secret manager to container, as file

no nice way to get the secret direct to your container environment.

So far, so good.

a other way to create

is to read from stdin with read -s SECRET. This way you have no traces in bash history.

$ read -s SECRET && echo -n $SECRET | podman secret create --replace MYSECRET - && unset SECRET 

a other way to inject

is to possible by composers 'command' or 'entrypoint' directive.

services:
  myservice:
...
  command: bash -c 'declare -x MYSECRET=$(cat /run/secrets/MYSECRET) && ./start-up.sh'
  secrets:
      - MYSECRET
...
secrets:
  MYSECRET:
    external: true

how it works

after inserting the secret over read it will be echoed without a newline (-n) and passed to podman secret create --replace MYSECRET -. This (—replace existing key) creates the key from stdin (–) you want to use in your compose.

In the compose file is the initial command replaced by the import of the key and followed from the start command.

You can get the command / entrypoint by using docker inspect RUNNING_CONTAINER_NAME --format='ENTRYPOINT: {{.Config.Entrypoint}} CMD: {{.Config.Cmd}}' and append them to the “new” command / entrypoint line.

The secret injection use bash to declare the content of your secret-file in the enviroment-variable name you like to have.

Thats it!

[1] https://www.redhat.com/en/blog/new-podman-secrets-command

But since 2025.1.2 #Bitwarden can Manage SSH-Keys and provide a SSH-Agent, too.

On MacOS it is necessary, that you configure the SSH-Agent that have to be used. Bitwarden provides the Information within a excellent Documentation.

Long Story short, for the Store-Version of Bitwarden:

Add the following Line to your .xxxrc or .xxxprofile -file to link to the Bitwarden-SSH-Agent and re-open your commandline.

export SSH_AUTH_SOCK=~/Library/Containers/com.bitwarden.desktop/Data/.bitwarden-ssh-agent.sock

After them, and the enabled Function in Bitwarden, you can use Bitwardens SSH-Agent with your synchronized Keys.

Thats it!

1. split the TLD from E-Mail-Address

   #set Domain
   if envelope :domain :matches "from" "*.*" {
   set :lower "domain" "${1}-${2}";
   }
   

   With this Information we are able to the Domain for later use.

2. split the localuser-Part and replace dots (.) by minus (–)

   #set from, replace . with -
   if envelope :localpart :matches "from" "*.*.*" {
   set :lower "localuser" "${1}-${2}-${3}";
   }
   elsif envelope :localpart :matches "from" "*.*" {
   set :lower "localuser" "${1}-${2}";
   }
   elsif envelope :localpart :matches "from" "*" {
   set :lower "localuser" "${1}";
   }
   

   With this we have a localuser part

3. at leased we try to find the right directory for the E-Mail to send in

   # domain in INBOX
   if mailboxexists "INBOX.${domain}" {
   fileinto "INBOX.${domain}";
   stop;
   }
   # E-Mail in INBOX
   if mailboxexists "INBOX.${localuser}+${domain}" {
   fileinto "INBOX.${localuser}+${domain}";
   stop;
   }
   

   Notice: a Plus-Sign (+) will be used at At-Sign (@) in the folder-structure.

In this example will all incoming mails sorted in Folder if there is a folder by Domain or fully sender Address in INBOX.

Have fun ;)

• Ofen, 230-190°C
• ca 30min Arbeit
• ca 60min Backzeit

Zutaten, für 1 – 2 Kuchen

1. Den Ofen auf 230°C vorheizen, Eier trennen und bereit stellen

2. Vermengen (im Mixer / Schüssel mit Rückgerät): Zucker, 1 TL Salz, Rum (optional), Sirup, Zimt, Ingwer, Muskat, Nelken, Eigelb, Sahne, Milch bis ein cremiges Püree entstanden ist

3. Das Eiweiß in einer Schale schaumig schlagen, 1 pr. Salz zugeben. Im weiteren in die Masse (2) unterheben.

4. unverzüglich in die Tortenschalen füllen, im Ofen backen bis eine leicht goldene Kruste entsteht, da nach den Ofen auf 190°C reduzieren und 25-30 Minuten backen lassen. (Die Mitte kann leicht feucht bleiben, wenn die Kruste zu braun wird, dann mit Abdecken)

5. Nach dem backen im Ofen 20-30 Minuten abkühlen lassen.

Wird warm Serviert, oder gut eingepackt im Kühlschrank zwei Tage haltbar (bei Zimmertemperatur servieren).

[1] https://food52.com/recipes/86591-julia-child-fluffy-pumpkin-pie-recipe/ [2] https://biancazapatka.com/de/kuerbispueree-3-arten-der-zubereitung/

Crowdin offers Badgets per Language, but they used an indexed #json #array. The #Badget jsonpath query select a specific, hardcoded index. In case the index change – you are fucked.

So i invent a solution for a working jsonpath query and offered #Crowdin to implement it. And they did!

old style

bevor the solution was implemented the query for languages looks like

$.progress.(n).data.translationProgress
$.progress.(n).data.approvalProgress

new style

the new jsonpath query is

$.progress[?(@.data.languageId==%27%bs%27%)].data.translationProgress
$.progress[?(@.data.languageId==%27%bs%27%)].data.approvalProgress

you need to notice, thats needed to escape the ' char as %27% to get it working.

Hopefully you can enjoy the new “feature”!

In my Example I need the #Basename of a #Repository. As you know, actions are saved in your Repository under the Path: .github/workflows/workflow.yaml

        #get Repository basename, use with ${{ env.REPO_NAME }}
      - name: get Repository name
        run: |
          echo "REPO_NAME=$(basename ${{ github.repository }})" >> $GITHUB_ENV


        # echo target repository basename
      - name: fetch translations
        run: 
          echp ${{ env.REPO_NAME }}

If found this working Solution on StackOverflow [1]

[1] https://stackoverflow.com/a/71799882

In my Example I tried to checkout source code, scan for Strings, append found Strings to a File and commit changes to separate repository.

As you know, actions are saved in your Repository under the Path: .github/workflows/workflow.yaml

steps:
        # check out source repository
      - name: checkout source repository (this)
        uses: actions/checkout@v3

        # check out target repository
      - name: checkout target
        uses: actions/checkout@v3
        with: 
          repository: example/target
          ssh-key: ${{ secrets.DEPLOY_SECRET }}

        # do your thing...
      - name: do things
        run: modify files in target...

      # commit to target repository
      - name: commit changes
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          repository: example/target

Explanation: -1. Checkout run with “example/source” -2․ Checkout run with “example/target” – used “with”: – repository to Checkout a other Repo – ssh-key for authentication (Deploy Key for target) -3. commit Changes, if found

Good luck!

The Focus of #Sieve points to #simplicity, #independency and #expandability from access method or platform. Sieve-Scripts run already in the Process of #Mail delivery on #Server-Side. Sieve supports #Plugins, like #LDAP.

Archiving Mails (like Mailinglists) by Date [2]:

require ["variables","date","fileinto","mailbox"];

# Extract date info
if currentdate :matches "year" "*" { set "year" "${1}"; }
if currentdate :matches "month" "*" { set "month" "${1}"; }

# Archive Dovecot mailing list items by year and month.
# Create folder when it does not exist.
if header :is "list-id" "dovecot.dovecot.org" {
  fileinto :create "INBOX.Lists.${year}.${month}.dovecot";
}

Sort Mails by Sender

# Mails from a mailing list will be put into the folder "mailinglist"
require "copy";
require "mailbox";
require "imap4flags";
require "fileinto";
if address :is ["From", "To"] "mailinglist@example.com" {
  fileinto "INBOX/mailinglist";
}

And many, many, many more possibilitys for Mailbox-Filter [2][3][4][5].

And there is a great Editor [6], too!

Sieve Editor [6]

https://github.com/thsmi/sieve

Sieve is a powerful scripting language for server-side mail filtering. It is intended to be used with IMAP which is ubiquitous. Many IMAP Servers are capable of running Sieve filters. Sieve stores and runs all scripts on the server-side.

Now there is the dilemma – you have access to a server supporting Sieve but how do you manage your scripts on this server?

You can use Telnet for this purpose, but that is far too uncomfortable, not applicable for a normal user and almost impossible with secure connections. Wouldn’t it be great to activate, edit, delete and add Sieve scripts with a convenient interface? That is exactly what this sieve editor offers…

[1] https://www.rfc-editor.org/rfc/rfc5228 [2] https://doc.dovecot.org/configuration_manual/sieve/examples/#archiving-a-mailinglist-by-date [3] https://en.wikipedia.org/wiki/Sieve_(mail_filtering_language) [4] https://p5r.uk/blog/2011/sieve-tutorial.html [5] https://support.tigertech.net/sieve [6] https://github.com/thsmi/sieve#sieve-editor

1. Download the latest #FileZilla Version (non-installer) [^1]
2. copy ./docs/fzdefaults.xml.example to ./fzdefaults.xml
3. set “Config Location” to “./”

<FileZilla3>
  <Settings>
    <Setting name="Config Location">./</Setting>
  </Settings>
</FileZilla3>

and you are ready to go with #FileZilla

[^1] https://filezilla-project.org/download.php?show_all=1

1. open Docker on your DSM and go to your Registrie
2. search your Image and Download the latest Version
3. switch to your Container Overview, stop and reset your Container
4. Run the Container again

Docker on DSM will now use the (newer) downloaded Image.

Good Luck!

[^1] https://mariushosting.com/synology-how-to-update-docker-image/