mox blog

Wireguard VPN Plugin for NetworkManager in GNOME

2021-01-27T00:00:00+01:00

Wireguard is a layer-3 secure network tunnel for ipv4 and ipv6. It has managed to remove the complexity that other solutions/VPN protocols like OpenVPN or IPSec brought, and also providing better performance.

Almost a year after being incorporated as a module in the linux kernel, this vpn solution continues growing and is becoming more and more popular.

So far it’s all praise. The only thing that I am still not used to is the stateless connections that Wireguard has by design. It means that we won’t have logging, peer connection status, etc.

I was also missing some sort of integration with NetworkManager. That’s why I ended up installing a plugin for NetworkManager in GNOME. I can now connect/disconnect the VPN, as I do with OpenVPN.

Thanks to the network-manager-wireguard repository it’s pretty easy to achieve. This is basically how I did it on Debian Buster:

$ sudo apt install build-essential libgtk-3-dev libnma-dev libsecret-1-dev

$ git clone https://github.com/max-moser/network-manager-wireguard
$ cd network-manager-wireguard

$ ./autogen.sh --without-libnm-glib

Output:
Build configuration: 
  --with-gnome=yes
  --with-libnm-glib=no
  --enable-absolute-paths=no
  --enable-more-warnings=yes
  --enable-lto=no
  --enable-ld-gc=yes


$ ./configure --prefix=/usr \
              --without-libnm-glib \
              --sysconfdir=/etc \
              --libdir=/usr/lib/x86_64-linux-gnu \
              --libexecdir=/usr/lib/NetworkManager \
              --localstatedir=/var

$ make   
$ sudo make install

Once installed, we can create a wireguard type connection:

The configuration itself is very simple, and not all fields are required. The only thing I haven’t been able to do is add more than one DNS server, it doesn’t seem to like the comma as separator.

Enjoy!

Atlassian Cloud: Pros and Cons

2020-12-24T01:59:34+01:00

Many companies are considering whether or not to migrate their Atlassian on-premise products to the Cloud option after announcing Atlassian that their Server options will be fully discontinued on February 2, 2024.

These are (imho) the most important points to consider before making decisions:

Data residency
Most apps in cloud are hosted by vendors
Single Sign-On Atlassian Connect
Jira Incident History and Confluence Incident History
Standard, Premium or Enterprise Product: Jira and Confluence

Preparing ACP-600 Project Administration in Jira Server: Part II Labs

2020-09-13T00:18:50+02:00

Let’s talk about the 24 hours lab that Atlassian provides when you buy the ACP-600 preparation course + exam bundle.

The preparation course is highly recommended and there is enough material to pass the exam. In addition, the exman only costs the same as buying the course + exam bundle.

As for the laboratory in particular. At the moment of activating it, you have 24 hours of access to it. The access is not automatically activated when buying the course, so you can organize yourself and activate the lab when you have more free time.

In my case, I spent about 8 hours with the lab, including documenting everything I was doing + some breaks in between. A pdf is already provided with all the steps detailed, though.

It is quite simple but if you want to consider it seriously, I recommend dedicating about 7-8h (maybe a Saturday at home?).

The exercises are well documented in the pdf and it is made in a way that you can try yourself before jumping to the next page and reading the solution.

I am not going to copy & paste anything from the PDF, as I would like to avoid any copyright violation, but I am going to document everything I have learned that I think is important, as short questions and answers. If you want to dive deep into any of the points, I recommend reading the official documentation.

Project Administration in Jira Server Lab: Questions and Answers

Permissions

When do we need a Jira Administrator? We need one when we need for example to create/edit…

New issue type
New screen
New workflow for some issue types, eg. we need a new workflow for Task and Bug issue types.
To remove a workflow condition
New field in some issue types
Edit permission scheme
Edit Issue security scheme
Edit priorities
Edit Notification scheme
New resolutions
New Issue link types
Edit the Field configuration: hidden, required, render, description
Edit Screen schemes or issue type screen schemes
Edit global permsissions: bulk, shared object, browse user, group filter subscription
Transition screen
Transition elements: triggers, conditions, validators, and post functions (A project admin can reuse a transition and its elements if they already exist)
Restrict transition to a group/role
Status properties
Custom fields: A Jira Administrator can set the context, where the field can be used (issue types)

Examples:

A Jira Administrator can create a condition to prevent specific groups/users from moving issues

And what can we do as Project Administrators? Here some examples:

Create versions
Edit screens
Remove transition in workflow
Remove statuses from workflow: If no issue is in that status. Don’t forget to remove its column on the Jira board, in case the project has one.
Reuse transitions: if has the same destination status. The transition elements will be reused as well (conditions, validators, etc.)
Delete issues
Modify reporter
Manage watch
Manage comments (require more permissions)
Manage worklogs (requires more permissions)

Use cases

Can’t move an issue to a specific status? Check if there is a transition to that status
Can’t users see the transition? A Condition might exist for that transition preventing the specific user of using it
Can’t edit fields on a screen? The screen might be being shared by other projects
Can’t see security level field? Enable Security level for the project
Users can “Configure Fields”: fields they want to see on screens
Can’t users hide the Summary field in “Configure fields”? Summary is a required field
Browse Projects permission? View project and its issues, use issue navigation
Permission scheme: add individual users? It’s not best practice. Better add roles (requires Jira Administrator perms)
Permission scheme has no global permissions (as share objects)
Merge versions? The old version will be removed and issues will be updated
Default Assignee? Can be: Component lead, unassigned, project default, project lead
Global transitions = statuses are able 2 transition 2 all
Add status (column) using board? It will be global transition
Add status (column) using board? If simplified workflow
Edit workflow? The project cannot be shared or be a system workflow. It requires to have extended permisssions
Extended Project Administration permission is enabled by default when using templates

Charts & Dashboards

Created vs Resolved Issues Report: backlog growing or shrinking
Time Report: length of time to resolve issues for a project or filter
user with most issues assigned? Use pie chart
where project issues are in the workflow? Pie chart: status
Single level group by report: Shows issues grouped by field
Team members can run reports
Edit dashboard? only owner or jira administrator
Default board administrator? Project lead when the project is created
Default board column names = workflow status names

Preparing ACP-600 Project Administration in Jira Server: Part I Concepts to master

2020-09-12T21:06:59+02:00

Here you can find what helped me to pass the exam ACP-600 Project Administration in Jira Server a couple of days ago. I hope it helps you too.

Feel free to leave a comment about your experience with the ACP-600 or any other Atlassian certification.

And as a recommendation I do think it works to do what I did and look for the answers yourself in the Atlassian documentation and write them down, as well as doing the labs! But in case you can’t find something, here is all the information to the points in the section “Important concepts to master” from the Exam Topics.

There is also a Part two of this guide with information about the Jira labs here.

Atlassian links:

Important concepts to master

Exam Topics: Important concepts to master
Issue: 15.04.2020

Which configurations are shared VS unique

Notice: No matter if we create a project using a template or with shared configuration, we will NOT automatically get versions and components created in our new project, as well as we will NOT share the project description.

When new projects are created from template

When we create a project using one of the templates that come with Jira (eg, templates: Scrum, Kanban and Basic in case of the Software project type) then 7 schemes will be automatically associated to the new project.
Some of the schemes are unique to the project and some are shared with other projects:

Unique schemes:

Issue Type Scheme
Issue Type Screen Scheme
Workflow Scheme

Unique schemes can be modified and the changes will not affect any other project.

Shared schemes:

Field Configuration
Notification Scheme
Permission Scheme
Priority Scheme

Changes to shared schemes will affect other projects.

When new projects are created with a shared configuration

When we create a project we can check the option: Create with shared configuration, in other words: copy an existing project.
All of that project’s schemes will be shared with the new project, which means that any change to a scheme will affect all the projects using that scheme.

Who can change a Project Key, and what are the effects on issues in the project

Only Jira administrators can change the Project Key.
Jira will start a background re-index once the project key is changed. It is limited to the project issues.

Post-update tasks

Fix the project entity links: when Jira is connected to another Atlassian application, entity links would have been automatically created between your Jira projects and the relevant “projects” in other applications, e.g. Confluence spaces. If we change the key of a Jira project, we will need to fix the project entity links.

Updating Jira Software agile board filters: if the Jira Software agile boards use the old project key, the board filters may need to be updated to reflect the new project key. Otherwise the board might not display issues from the renamed project.

Which project details can be added and changed by Project Administrators

As a project admin, we can edit our project’s:

Name
URL
Avatar
Description
Project lead
Default assignee
Sidebar shortcuts

Only Jira administrators can edit the project key, project type, and category.

What are the uses of Project Category in Jira

Project categories are useful in large enterprise instances. The uses are:

Searching for all the issues in a particular project category using JQL.
Projects sorted by category.

A Jira project can only belong to one category.

What features are available for Jira Software vs Jira Core

Jira Software provides the Project types Software and Business.
Jira Core provides just the Project type Business.

Under those two categories there are available a number of project templates:

Software project type: Scrum, Kanban, and Basic.
Business project type has: Project management, Process management, and Task management templates.

A project template is a set of pre-configurations which will be our starting point when we create a new project.

What is the importance of the Browse Projects permission

Browse Projects permission allows users to see projects, view their issues, and search for them in Issue Navigator.

It is the most important permission and by default, all logged in users with application access have the Browse Projects permission.

How do combinations of permissions work together to enable specific actions

Combinations of permissions are sometimes needed to complete certain actions.

What permissions are needed to Move Issues

Movie Issues requires Create Issue permission in the target’s project.

Move Issues permission allows to move issues:

From one project to another.
From one issue type to another.
From one workflow to another workflow within the same project.

What permissions are needed to Edit or Delete All Worklogs

The permissions needed are:

Work On Issues
Edit All Worklogs
Delete All Worklogs

Only relevant if time tracking is enabled.

What permissions are needed to rank issues in the backlog

The project permissions that are required for ranking issues in JIRA Agile Classic Planning Board are:

Schedule Issues
Edit Issues

The same permissions are also required for scheduling issues in JIRA Agile Classic Planning Board.

What permissions are needed to assign issues to yourself

Two permissions are required to assign issues to ourselfes:

Assign issues: permission to assign issues to users. Also allows autocompletion of users in the Assign Issue dropdown.
Assignable user: Permission to be assigned issues. This does not include the ability to assign issues.

What requirements must a user meet in order to use a particular workflow transition

The requirements to use a particular workflow transition are:

Transition Issue project permission.
The user has to meet the workflow Conditions specified for the transition, if any.

What is an Issue Collector and what permissions are needed to configure it

Issue Collector allows us to embed the feedback form into a website.

When the user submits the Jira feedback form, an issue is conveniently created in Jira.
The permissions required to configure it is, in case of creating an Issue Collector:

Jira Administrators Global permission

If we are editing an issue collector, we need the following permissions in the project.

Administer projects
Create Issues
Assignable user

Where are all the places you need to look to fully identify what permissions a particular user has

To identify what permissions a particular user has, we look at:

Application access: needed to log in and to use the features of a particular Jira product (Core, Software, Service Desk).
Global permissions: system wide permissions that are granted to groups of users.
Permission schemes: specify what users can do in a particular project. It is a set of users groups or project roles assignments.
Project roles: allow to associate users and/or groups with particular projects.

What are the use cases where it is best to use Project Roles rather than Groups

Project roles help to reduce the number of schemes.
Project administrator can manage membership of the project.
Changes can be made quicker when membership changes.
Using project roles reduce Jira administrator’s work.

Which business requirements necessitate the use of separate issue types in a project

Different Issue Types are needed if:

Issues types have different workflows.
Issues have different required or hidden fields.
Issues need different screens when creating, editing or viewing.
And issues need to be reported on separately.

What is the relationship between screens, screen schemes and issue type screen schemes

A screen is just a collection of fields.
Screens are mapped to issue operations: Create Issue, Edit Issue, and View Issue.
The mapping of screens to issue operations is called screen schemes and has to be done by Jira Administrators.
The mapping of screen schemes to issue types is called issue type screen scheme.
And then the issue type screen scheme can be applied to one or more projects.

Issue Type Screen Scheme
Screen Schemes			Mapped to
Operation	Screen	Screen scheme	Issue Type
CREATE	Screen A	Screen Scheme 1	Bug Enhancement
EDIT	Screen B	Screen Scheme 1
VIEW	Screen C	Screen Scheme 1
Operation	Screen	Screen scheme	Issue Type
CREATE	Screen D	Screen Scheme 2	Task
EDIT	Screen D	Screen Scheme 2
VIEW	Screen D	Screen Scheme 2

Field configurations list all the system fields and the custom fields available in the JIRA instance to be used in screens, schemes, and issue schemes.

A Field configuration specifies to JIRA what is the behavior of a field when it is applied to an issue type. Jira Administrators can change following of a field:

Optional or required
Hidden or visible
Description
Renderer used by the field

Also Fields appear in Transition screens.

Transition screens are used when information is needed as an issue moves through its workflow.

Only Jira Administrators can edit Field configurations and configure Transition screens.

How do you determine the maximum number of screens possibly used in a project (for issue operations and workflow transitions)

The maximum number of screens is = ( 3 * number of issue types ) + number of workflow transitions

A issue type can have a maximum of 3 screens, one for each operation (create, view and edit).
A workflow in a project can have 1 transition screen per transition.

Who can make changes to screens, screen schemes and issue type screen schemes

Info: Project administrators can edit their project’s screens as long as they

are not shared with any other projects.
are not a default system screen.
are not used as a transition screen.

Info: Only Jira Administrators can…

create screens.
create/edit screen schemes.
create/edit issue type screen schemes.

What are all the various factors that influence whether a field is visible on a screen

These are the factors that determine if a field is visible on a screen:

The field is not on the screen. Jira Administrators can remove fields from screens or the field was never added.
The field is hidden in the field configuration.
The field context may not be for the right project and/or issue type.
The field has no value yet.
The field has been hidden by the user through their Configure Fields settings.
The user does not have the right permission.

When is it best to use components, and when is it best to use a custom field instead

Components allow us to categorize issues in large groups, for example: Database, Localization, Login, User Interface, etc.
They are optional in a proect.

Components are used when:

The issue may belong to more than one category.
The field value must be managed by the project administrator
The assignee must be set based on the selected value. Eg: Tom is Componente Lead, we can set then the Component Lead as the default asignee.

Custom fields can be also used to categorize, when:

The field must have a default value.
The field options are shared across projects.

What are the features, uses, limitations/restrictions of workflow changes, especially the Simplified Workflow

The Workflow of the project determines which statuses ara available in that project.

A project uses either a Jira Workflow or the Simplified Workflow to control the transitioning of issues from one status to another.
All Jira Software projects use the Simplified Workflow by default.

The Simplified Workflow is very basic and it allows issues to transition from any status to any other status: global transitions; either from inside an issue or by dragging issues on the board.

The Simplified Workflow can only be used if a board represents a single project.

Who can change the Simplified Workflow? What are the limitations on changes to the Simplified Workflow

Jira Administrators or Project Administrators with Extended Project Administration.

Users who are both Project Administrators and Board Administrators can change the Simplified Workflow via the board configuration.

Once we edit a Simplified Workflow adding statuses and transitions it becomes a Custom Workflow.

What changes can be performed on statuses and transitions

The statuses can be changed. The transitions can also be changed but nothing about validators or conditions can be modified.

Once we edit a Simplified Workflow adding statuses and transitions, it is no longer a Simplified Workflow and becomes a Custom Workflow.

A customized workflows is usually a more complex workflow. Often it has a specific sequence of steps rather than allowing every status to transition into every other status (global transitions). The Jira administrator may add conditions, user input validation and automated functions to transitions in the workflow.

What things may need to be updated as a result of workflow changes of any kind

The status of an issue may need to be changed if the original status, which the issue had, has been removed.

What workflow changes can be done through the board by Board Administrators

Add columns to a board and map statuses.
Switch to the Simplified Workflow.

What types of workflow changes can Project Administrators make if Extended Project Administration is enabled

A Project Administrator needs the Extended Project Administration permission in order to edit workflows and screens in a project.

Project Administrators can edit their project’s workflow if the workflow:

Is not shared with any other projects.
Is not the Jira default system workflow, which cannot be edited at all.

Project Administrators cannot edit the workflow to the same extent as a Jira Administrator. The restrictions are:

To add a status, the status must already exist in the Jira instance i.e. the Project Administrator can’t create new statuses or edit existing statuses. However, if the Project Administrator is also a Board Administrator, they can add a new status to the board (which creates a new status in Jira).
To remove a status, the status must not be used by any of the project’s issues.
The Project Administrator can create, update (name and description) or delete transitions, but they can’t select or update a screen used by the transition, or edit or view a transition’s properties, conditions, validators or post-functions.

Note: You can end up with a lot of statuses if users can freely add their own statuses to their boards in their projects!

How do these settings affect notifications

AutoWatch setting

AutoWatch setting controls whether we automatically watch an issue we create or comment on.

My Changes setting

My Changes setting tells Jira to email us (or not) when we make a change in an issue and we get included in the list of people to be emailed about it.

Share This Issue setting sends e-mails to the people we share with.

@Mentions

@Mentions defines whether or not to be notified via e-mail when we are mentioned.

Filter Subscriptions

Filter Subscriptions sends us the results of filters on a regular basis.

What are the configuration options for all the out-of-box reports and gadgets (except Agile reports and gadgets)

What is their behavior and expected results

There are three main types of reports: Agile, Issue analysis, and Forecast & management.

The Issue analysis and Forecast & management reports are general reports applicable to all project types for analyzing issues and seeing if your projects are on track.

Issue analysis reports are:

Average Age Report: Shows the average age of unresolved issues for a project or filter. This helps you see whether your backlog is being kept up to date.
Created vs. Resolved Issues Report: Maps created issues versus resolved issues over a period of time. This can help you understand whether your overall backlog is growing or shrinking.
Pie Chart Report: Shows a pie chart of issues for a project/filter grouped by a specified field. This helps you see the breakdown of a set of issues, at a glance.
Recently Created Issues Report: Shows the number of issues created over a period of time for a project/filter, and how many were resolved. This helps you understand if your team is keeping up with incoming work.
Resolution Time Report: Shows the length of time taken to resolve a set of issues for a project/filter. This helps you identify trends and incidents that you can investigate further.
Single Level Group By Report: Shows issues grouped by a particular field for a filter. This helps you group search results by a field and see the overall status of each group.
Time Since Issues Report: For a date field and project/filter, maps the issues against the date that the field was set. This can help you track how many issues were created, updated, etc, over a period of time.

Configuration Options:

Project or saved filter
Period: Hourly, Daily, Weekly,…
Days previously: 30

Forecast & management reports are:

Time Tracking Report: Shows the original and current time estimates for issues in the current project. This can help you determine whether work is on track for those issues.
User Workload Report: Shows the time estimates for all unresolved issues assigned to a user across projects. This helps you understand the user’s workload better.
Version Workload Report: Shows the time estimates for all unresolved issues assigned to a version, broken down by user and issues. This helps you understand the remaining work for the version.

Configuration Options:

Version
Sorting
Issues
Subtask inclusion

How are valid JQL queries written

We need to know what we are searching for:

Field name e.g. project
Operator e.g. equals, contains, etc.
Field value e.g. Teams in Space

Query: Return ALL issues in the Teams in Space project

Field Operator Field Value project = “Teams in Space”

What operators and arguments are valid for various JQL functions (e.g. membersOf(), StartOfDay(), WAS, CHANGED, etc.)

The list is pretty long so better to check the official docs:

Advanced Searching Functions

Which export options are available from the Issue Navigator

Click Export at the top of the page.

Here you see all the different ways you can export your search to reuse in other contexts:

Printable, full content, RSS (Issues), RSS (Comments), CSV (All fields), CSV (Current fields), HTML (All fields), HTML (Current fields), XML, Word, Dashboard Carts

Bonus points

Difference between Workflow Conditions and Workflow Validators

Conditions allow or prevent workflow transitions to be executed. In other words, Transition buttons will not be shown on the View Issue page if a condition fails, thus the user will not be able to execute the transition.

Using conditions on workflows are best practices and can be used e.g., as follow:

Allow only members from a specific group to execute a transition.
An issue has passed through a required status.
A field contains a required value.

Conditions cannot validate input parameters gathered from the user on the transition’s screen. For that we would use validators.

Validators validate the input after the transition button has been clicked, but before the transition has been performed. When they fail, the issue does not go to the destination status of the transition. The transition’s post functions are not executed.

Example of validators can be:

Checking that a field has been updated.
A date is within a specific range.

Tainted filename errors in Exim 4.94

2020-07-25T00:00:00+02:00

After upgrading Exim to 4.94.1 the logs start showing errors regarding tainted filenames and e-mails are being temporarily rejected.

If the error is “taint mismatch”, then that’s an exim bug. Otherwise, it is a configuration problem: https://bugs.exim.org/show_bug.cgi?id=2587

Upgrading notes

Exim version 4.94

Some Transports now refuse to use tainted data in constructing their delivery location; this WILL BREAK configurations which are not updated accordingly. In particular: any Transport use of $local_part which has been relying upon check_local_user far away in the Router to make it safe, should be updated to replace $local_part with $local_part_data.

After a proper lookup the untainted data is in $local_part_data.
The tainted attribute is sticky, so just copying the content does not remove that attribute.

Tainted not permitted

One of the errors that can be encountered is:

Tainted '/home/mail/user@example.com' (file or directory name for transport_test transport) not permitted

The problem there is that the filename uses tainted data from both $local_part and $domain. The Exim config might contain something like this that has been working in Exim 4.93.x:

# router
test_router:
  driver = accept
  domains = !+local_domains
  transport = test_transport

# transport
test_transport:
  driver = appendfile
  maildir_format
  directory = /home/mail/${local_part}@${domain}

In order to fix that issue, we would replace router and transport (if that’s the case) for something like this:

# router
test_router:
  driver = accept
  domains = lsearch;/etc/exim/domainlist
  local_parts = lsearch;/etc/exim/domainlist/$domain_data
  transport = test_transport

# transport
test_transport:
  driver = appendfile
  maildir_format
  directory = /home/mail/${local_part_data}@${domain_data}

Tainted filename for search

That’s another possible error that might be encountered after upgrading Exim. This is an example of what can be found in the logs:

Tainted filename for search: '/etc/exim/aliases/mx.example.com' temporarily rejected RCPT <test@example.com>: failed to expand "${if exists{/etc/exim/aliases/$domain}{${lookup{$local_part}lsearch{/etc/exim/aliases/$domain}}}}": NULL

We have a list lookup: “domains = ”

$domain expands to tainted data. If we concatenate $domain to anything, the result will be a tainted string.
In this case: /etc/exim/aliases/$domain is tainted and we may not use that as a filename for a lookup.

We have to use a detainted value rather than $domain in $domain_data, but we need to look at the actual definition of our local_domains list and work out what the lookup against it will do.

system_aliases:
  driver = redirect
  data = ${if exists{/etc/exim/aliases/$domain}{${lookup{$local_part}lsearch{/etc/exim/aliases/$domain}}}}
  domains = mx.example.com

This is a possible solution using untainted $local_part_data and $domain_data:

system_aliases:
  driver = redirect
  data = $local_part_data
  domains = dsearch,ret=full;//etc/exim/aliases
  local_parts = lsearch;$domain_data

kubectl without so much typing

2020-06-24T00:00:00+02:00

kommands

kubernetes common commands without so much typing

install

git clone https://github.com/javimox/kommands ~/.kube/kommands/

bash

echo "source ~/.kube/kommands/.kommands" >> ~/.bashrc
source ~/.bashrc

zsh

echo "source ~/.kube/kommands/.kommands" >> ~/.zshrc
source ~/.zshrc

usage

All the commands below accept as parameter a number or a name. Autocomplete is enabled for names.

kommands get and their kubectl equivalents

kgpo  : kubectl get pods
kgpvc : kubectl get pvc
kgsvc : kubectl get svc

kommands del

kdpo  : kubectl delete pod
kdpvc : kubectl delete pvc
kdsvc : kubectl delete svc

kommands apply:

kapp  -> kubectl apply -f

kommand describe:

kdesc -> kubectl describe

kommands logs:

klog  -> kubectl logs -f

kommand show containers
ksco : it returns the name of the containers that run in a specific pod.

kommand execute sh
kesh : it opens a shell in a specific pod/container.

examples

get pods and their number

$ kgpo 
NAME                 READY   STATUS             RESTARTS   AGE
echo-pod-pvc         0/1     Pending            0          103m
first-pod            1/1     Running            0          2d6h
pod-two-containers   2/2     Running            0          83m

get pod number 3

$ kgpo 3
 0 NAME                 READY   STATUS             RESTARTS   AGE
 3 pod-two-containers   2/2     Running            0          84m

show containers of the pod number 3

$ ksco 3
NAME
i-am-the-first-container-in-this-pod
i-am-then-the-second-container

open a shell in a container of a pod using names

$ kesh pod-[TAB] [TAB]
i-am-the-first-container-in-this-pod  i-am-then-the-second-container

$ kesh pod-two-containers i-am-then-the-second-container
You are now in pod: pod-two-containers -c i-am-then-the-second-container
/ # 

open a shell in a container of a pod using numbers

pod number 3 , container number 2

$ kesh 3 2
You are now in pod: pod-two-containers -c i-am-then-the-second-container
/ # 

get persistent volume claims

$ kgpvc
NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
echo-cache2   Bound    pvc-49704fde-7d19-446c-b9f2-192e297e7f0a   1Gi        RWO            do-block-storage   111m
pvc-1         Bound    pvc-4e902e87-0df7-4c3c-827c-a8c7cfd75fa5   1Gi        RWO            do-block-storage   93m

delete persistent volume claim using its number

$ kdpvc 2
do you want to remove pvc-1 (y/N)? y
persistentvolumeclaim "pvc-1" deleted

get services

$ kgsvc
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
echo-web-svc-nodeport   NodePort    10.245.124.76    <none>        8080:31777/TCP   112m
kubernetes              ClusterIP   10.245.0.1       <none>        443/TCP          2d6h
test-app                ClusterIP   10.245.109.229   <none>        8080/TCP         113m

describe service number 3

$ kdesc svc 3
Name:              test-app
Namespace:         default
Labels:            name=test-app
Annotations:       Selector:  app=echo-app
Type:              ClusterIP
IP:                10.245.109.229
Port:              echo  8080/TCP
TargetPort:        8080/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

apply manifest

$ kapp pod-1.yaml
pod/first-pod created

show logs of the pod using numbers

pod number 2 , container number 2

$ klog 2 2
You are now showing logs of: pod-two-containers i-am-then-the-second-container
Fri Jun 26 23:00:04 UTC 2020
Fri Jun 26 23:00:05 UTC 2020
Fri Jun 26 23:00:06 UTC 2020
Fri Jun 26 23:00:07 UTC 2020

links

License: GPLv3
GitHub Repo: kommands

visual mode not implemented in vi using termux

2020-06-15T18:34:10+02:00

When using vi on Termux we might have the issue that the visual mode is not implemented.

'v' is not implemented

That probably happens because we are using the vi delivered with busybox. To use the visual mode and some other vi options we install vim

pkg in vim

Michael Servetus

2020-06-07T00:00:00+02:00

da ich für meinen Deutschunterricht über einen historischen Moment oder eine einflussreiche Person schreiben könnte habe ich mich für Michael Servetus (Miguel Servet) entschieden.

Das ist eine kurze Zusammenfassung über sein Leben:

Am 27. Okt. 1553 wurde Miguel Servet als Ketzer in Genf verbrannt.

Dieses Ereignis erzeugte eine geistige Strömung, die unter anderem die Theorie des grundsätzlichen religiösen Toleranz verteidigte, die Jahre später in Europa durchgesetzt wurde.

Miguel Servet wurde 1511 in Huesca, Spanien geboren. Er war seiner Zeit als Humanist und Arzt sowie als Theologe voraus.

Als er 13 Jahre alt war, sprach er Latein, Griechisch und Hebräisch. Später lernte Miguel Servet noch Italianisch, Französisch und Deutsch.

Er ist dafür bekannt, das Konzept der Heiligen Dreifaltigkeit in Frage gestellt zu haben, sowie für die Entdeckung des Lungenkreislaufs.

Seit er 20 Jahre alt war, musste Servetus seine Werke unter Pseudonyme veröffentlichen.

Servetus ist eine der repräsentativen Figuren des freien Denkens und eine Repräsentation der grausamen Handlungen religiöser Institutio en im Laufe der Geschichte: Er wurde von Johannes Calvin verfolgt und wegen seiner Meinungen wurde er zur Verbrennung als Ketzer mit grünen Hölzern verurteilt.

Quellen:

mox helm repository goes live

2020-04-18T00:00:00+02:00

This website hosts now a helm repository. Yay!

The links to the repo are:

More info about in Helm Repo

Have fun!

Exclude Post from Search Index