Note in order to run gitk from terminal you need to have a Desktop GUI environment (for example VNC).
gitk is a graphical history viewer. Think of it like a powerful GUI shell over git log and git grep. This is the tool to use when you’re trying to find something that happened in the past, or visualize your project’s history
Install gitk
For CentOS and RedHat:
1
yum install -y gitk
Usage
gitk is easy to invoke from the command-line. Just cd into your target git repository, and type:
1
gitk
Then a dedicated GUI will be launched for you:
You can get a brief usage introduction from man gitk, for example, if I want to see the commit history of hello.sh
When run git pull origin master to make your local branch up-to-date, if there are files need to be merged, you will get prompt to confirm the merge and make commit. This is not good for automation, need to mute this prompt.
Note this method fits this situation, but not sure if this is a general way to go, because git pull has different syntax format.
Actually, git pull does a git fetch followed by git merge, so can sepetate it into two steps:
I have got chance to learn something about SELinux (Security-Enhanced Linux). This is a online training from O’REILLY.
The Linux operating system was never designed with overall security in mind, and that’s exactly where SELinux comes in. Using SELinux adds 21st century security to the Linux operating system. It is key to providing access control and is also an important topic in the Red Hat RHCSA, CompTIA Linux+ and Linux Foundation LFCS exams.
total 4 drwx------ 4 root root 37 May 8 15:21 imagedb drwx------ 5 root root 45 May 8 15:22 layerdb drwx------ 4 root root 58 May 8 15:29 distribution -rw------- 1 root root 1269 Jun 17 09:21 repositories.json
使用Docker镜像
dangling image doesn’t have name and tag (present as <none>), docker commit sometimes can generate dangling image, you can use filter to show dangling:
1
docker images --filter "dangling=true"
只显示image ID:
1
docker images -q
Remove all dangling images:
1 2 3
# if no use {} in xargs # the input arguments will be placed at end: docker rmi xxx docker images --filter "dangling=true" -q | xargs docker rmi
There is a tool dockviz can do image analysis job. 可以图形化的展示image的层次。
I have some doubts about Security Context Constraint (SCC) in OpenShift, for example, I give privileged SCC to service account, but some containers are still running as non-root user.
First what is SCC used for: control the actions that a pod can perform and what it has the ability to access, also very useful for managing access to persistent storage.
Prerequisite
Spin up a fresh OpenShift Enterprise cluster with version:
It will fail to pull the image from demo1-ds (describe pod can see) because we deploy objects on project demo1-proj, it doesn’t have the permission to pull image from other project, let’s enable it:
By default, when a container or pod does not request a user ID under which it should be run, the effective UID depends on the SCC that emits this pod. Because restricted SCC is granted to all authenticated users by default, it will be available to all users and service accounts and used in most cases.
Name:restricted Priority:<none> Access: Users:<none> Groups:system:authenticated Settings: Allow Privileged:false Default Add Capabilities:<none> Required Drop Capabilities:KILL,MKNOD,SETUID,SETGID Allowed Capabilities:<none> Allowed Seccomp Profiles:<none> Allowed Volume Types:configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret Allowed Flexvolumes:<all> Allow Host Network:false Allow Host Ports:false Allow Host PID:false Allow Host IPC:false Read Only Root Filesystem:false Run As User Strategy:MustRunAsRange UID:<none> UID Range Min:<none> UID Range Max:<none> SELinux Context Strategy:MustRunAs User:<none> Role:<none> Type:<none> Level:<none> FSGroup Strategy:MustRunAs Ranges:<none> Supplemental Groups Strategy:RunAsAny Ranges:<none>
The restricted SCC uses MustRunAsRange strategy for constraining and defaulting the possible values of the securityContext.runAsUser field. The admission plug-in will look for the openshift.io/sa.scc.uid-range annotation on the current project to populate range fields, as it does not provide this range. In the end, a container will have runAsUser equal to the first value of the range that is hard to predict because every project has different ranges.
You see, here openshift.io/sa.scc.uid-range start from 1000130000, is the UID of our busybox container.
SCCs are not granted directly to a project. Instead, you add a service account to an SCC and either specify the service account name on your pod or, when unspecified, run as the default service account.
Add and Remove SCC
Add service account default in project demo1-proj to SCC privileged
Then login as demo1, go to demo1-proj, deploy again:
1
oc apply -f bb-deploy.yml
1 2 3 4
oc exec -it bb-deployment-78bdb8c4f-rgj88 sh
/ $ id uid=1000130000 gid=0(root) groups=1000130000
Why the UID is still 1000130000? We have applied privileged right?
Because privileged is just a constraint, you need to Ensure that at least one of the pod’s containers is requesting a privileged mode in the security context.
So update the yaml file, add securityContext, and deploy again:
Here we overwrite some env variables to change the default configuration.
Also follow the instruction in docker web, instruct every docker daemon to trust that certificate. The way to do this depends on your OS, for Linux:
1 2 3
mkdir -p /etc/docker/certs.d/<docker registry domain>/ ## copy domain.crt (generate by openssl) to this folder on every Docker host cp /root/certs/domain.crt /etc/docker/certs.d/<docker registry domain>/
If you don’t do this, when run docker push you will get this error:
1
Error response from daemon: Get https://chengdol.registry.com/v2/: x509: certificate signed by unknown authority
If docker still complains about the certificate when using authentication?
When using authentication, some versions of Docker also require you to trust the certificate at the OS level.
So far, secure configuration is done, now the docker registry will use HTTPS in 443 port to communciate with docker client. If you want to setup basic authentication, see below:
Setup Basic Authrntication
Warning: You cannot enable authentication that send credentials as clear text. You must configure TLS first for authentication to work.
Do the same trust thing in every docker host, under /etc/docker/certs.d/ directory, we create a folder <docker registry domain>:5000 and put domain.crt in it:
1 2 3
mkdir -p /etc/docker/certs.d/<docker registry domain>:5000/ ## copy domain.crt (generate by openssl) to this folder on every Docker host cp domain.crt /etc/docker/certs.d/<docker registry domain>:5000/
A Docker repository is a hosted collection of tagged images that, together, create the file system for a container
A Docker registry is a host that stores Docker repositories
An Artifactory repository is a hosted collection of Docker repositories, effectively, a Docker registry in every way, and one that you can access transparently with the Docker client.
## exit will delete the pod automatically ## --restart=Never: create a pod instead of deployment ## praqma/network-multitool: network tools image alias kbt='kubectl run testpod -it --rm --restart=Never --image=praqma/network-multitool -- /bin/sh'
## docker shortcut alias di='docker images' alias dp='docker ps -a' alias dri='docker rmi -f' alias drp='docker rm -f'
alias k='kubectl' alias kbn='kubectl get nodes' ## can replace with your working namespace ## pods alias kbp='kubectl get pods --all-namespaces' ## deployments alias kbd='kubectl get deploy -n zen | grep -E "xmeta|services"' ## statefulsets alias kbsts='kubectl get sts -n zen | grep -E "conductor|compute"' ## services alias kbs='kubectl get svc -n test-1'
## get into pods kbl() { pod=$1 ## get namepace ns=$(kubectl get pod --all-namespaces | grep $pod | awk {'print $1'}) kubectl exec -it $pod sh -n $ns } ### for fixed pod name alias gocond='kubectl exec -it is-en-conductor-0 bash -n test-1' alias gocomp0='kubectl exec -it is-engine-compute-0 bash -n test-1' ### for dynamic pod name goxmeta() { isxmetadockerpod=`kubectl get pods --field-selector=status.phase=Running -n test-1 | grep is-xmetadocker-pod | awk {'print $1'}` kubectl exec -it ${isxmetadockerpod} bash -n test-1 }
Sometimes after I git pull from the master branch, if I run git status, there are some files (for me it’s mainly xxx.dsx) are modified that need to be added and committed, that’s strange.
It seems the format issue that can be solved by editting the top level .gitattributes in your local repository. Open .gitattributes, comment out the formulas, for example:
1
#* text=auto
Now if I run git status again, the clutters are gone and git outputs only show
1
modified: .gitattributes
Then revert back to origin in .gitattributes and run git status again, the branch will be clean.
Acutally there are some commands can exterminate editor operation:
1 2 3 4
sed -i -e 's/^\(\*[ ][ ]*text.*\)/#\1/' .gitattributes git status sed -i -e 's/^#\(\*[ ][ ]*text.*\)/\1/' .gitattributes git status