July 2019
« Jun    


WordPress Quotes

I've learned that you shouldn't go through life with a catcher's mitt on both hands; you need to be able to throw something back.
Maya Angelou
July 2019
« Jun    

Short Cuts

2012 SERVER (64)
2016 windows (9)
AIX (13)
Amazon (36)
Ansibile (19)
Apache (134)
Asterisk (2)
cassandra (2)
Centos (211)
Centos RHEL 7 (267)
chef (3)
cloud (2)
cluster (3)
Coherence (1)
DB2 (5)
DISK (25)
DNS (9)
Docker (30)
Eassy (11)
ELKS (1)
Fedora (6)
ftp (5)
GIT (3)
GOD (2)
Grub (1)
Hacking (10)
Hadoop (6)
health (1)
horoscope (23)
Hyper-V (10)
IIS (15)
JAVA (7)
JBOSS (32)
jenkins (1)
Kubernetes (7)
Ldap (5)
Linux (188)
Linux Commands (166)
Load balancer (5)
mariadb (14)
Mongodb (4)
MQ Server (24)
MYSQL (84)
Nagios (5)
NaturalOil (13)
Nginx (35)
Ngix (1)
openldap (1)
Openstack (6)
Oracle (35)
Perl (3)
Postfix (19)
Postgresql (1)
PowerShell (2)
Python (3)
qmail (36)
Redis (12)
RHCE (28)
Security on Centos (29)
SFTP (1)
Shell (64)
Solaris (58)
Sql Server 2012 (4)
squid (3)
SSH (10)
SSL (14)
Storage (1)
swap (3)
TIPS on Linux (28)
tomcat (62)
Uncategorized (29)
Veritas (2)
vfabric (1)
VMware (28)
Weblogic (38)
Websphere (71)
Windows (19)
Windows Software (2)
wordpress (1)

WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.

Who's Online

20 visitors online now
1 guests, 19 bots, 0 members

Hit Counter provided by dental implants orange county

COPY and ADD commands in Dockerfile

COPY and ADD commands in Dockerfile

Two very similar commands COPY and ADD are provided in the Dockerfile. This article attempts to explain the basic functions of these two commands, as well as their similarities and differences, and then summarize their respective suitable application scenarios.

Build context concept
When you create a mirror from a Dockerfile using the docker build command, a build context is generated. The so-called build context is the collection of files in the path specified by the PATH or URL of the docker build command. Any file in the context can be referenced during the image build process, such as the COPY and ADD commands we will introduce, to reference the files in the context.

By default, the docker build -t testx . command in the command indicates that the build context is the current directory. Of course we can specify a directory as the context, such as the following command:

$ docker build -t testx /home/mohan/hc

We specify the /home/mohan/hc directory as the build context. By default, docker will use the Dockerfile found in the root of the context.

The COPY and ADD commands cannot copy local files outside the context.
For COPY and ADD commands, if you want to copy a local file to an image, the local file must be a file in the context directory.
In fact, this is a good explanation, because when the build command is executed, the docker client will send all the files in the context to the docker daemon . Considering that the docker client and the docker daemon are not on the same machine,

the build command can only get the file from the context. If we reference a file that is not in the context in the COPY and ADD commands of the Dockerfile, we receive an error similar to the following:

Work with WORKDIR

The WORKDIR command configures the working directory for subsequent commands such as RUN, CMD, COPY, and ADD. After the WORKDIR command is set, the relative path in the next COPY and ADD commands is the path specified relative to WORKDIR. For example, we add the following command to the Dockerfile:

COPY checkredis.py .

Then build a container image named testx and run a container to view the file path:

The checkredis.py file is copied to the WORKDIR /app directory.

The simplicity of the COPY command
If you just copy the local file to the container image, the COPY command is the most appropriate. The format of the command is:
COPY <src> <dest>

In addition to specifying the full file name, the COPY command also supports Go-style wildcards, such as:

COPY check* /testdir/ # Copy all files at the beginning of
check COPY check?.log /testdir/ # ? is a placeholder for a single character, such as matching file check1.log

For directories, the COPY and ADD commands have the same characteristics: only copy the contents of the directory and not the directory itself. For example, we add the following command to the Dockerfile:

COPY mohandir .

The structure of the mohandir directory is as follows:

There are only file1 and file2, and there is one less directory mohandir. If you want file1 and file2 to be saved in the mohandir directory, you need to specify the name of the directory in the target path, for example:

COPY mohandir ./mohandir

One use of the COPY command from the ADD command is in a multistage scenario. For an introduction and usage of multistage, please refer to the author’s article ” multi-stage in Dockerfile “. In the multistage usage, you can use the COPY command to copy the product from the previous stage to another image, such as:

FROM golang: 1.7.3
WORKDIR /go/src/github.com/sparkdevo/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux Go build -a -installsuffix cgo -o app .

FROM alpine:latest
RUN apk –no-cache add ca-certificates
WORKDIR /root/
COPY –from=0 /go/src/github.com/sparkdevo/href-counter/app .
CMD [“./app”]

This code is referenced in the article ” multi-stage in Dockerfile “, where the COPY command copies the product of the previous stage build into the current image by specifying the –from=0 parameter.

The ADD command can also do other things.
The format of the ADD command is the same as the COPY command, which is also:
ADD <src> <dest>

In addition to the fact that it can’t be used in multistage scenarios, the ADD command can do all the functions of the COPY command, and it can also do two cool features:

Extract the compressed files and add them to the image
Copy files from url to image
Of course, these features also make the ADD command more complicated and less intuitive than the COPY command.

Extract the compressed files and add them to the image.
If we have a compressed file package, we need to add the files from this compressed package to the image. Do you need to unpack the package and then execute the COPY command? Of course not needed! We can do this once with the ADD command:

ADD mohandir.tar.gz .

This should be the best use case for the ADD command!

Copying files from url to images
is a much more cool usage! However, in the best practices of the official documentation of docker , it is strongly recommended not to use this! ! The docker officially recommends that when we need to copy files from a remote location, it is best to use the curl or wget commands instead of the ADD command. The reason is that when using the ADD command, more mirror layers are created, and of course the size of the image will be larger (the two pieces of code below are from the docker official documentation):

ADD http://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C / Usr/src/things all

If you use the following command, not only does the number of layers in the image decrease, but the big.tar.xz file is also not included in the image:

RUN mkdir -p /usr/src/things \
&& curl -SL http://example.com/big.tar.xz \
| tar -xJC /usr/src/things \
&& make -C /usr/src/things All

Well, it seems that the ADD command is only needed when extracting compressed files and adding them to the image!

Tips for speeding up image construction
When using the COPY and ADD commands, we can use some tricks to speed up the mirror build process. For example, put the copy operation of the files that are least likely to change in the lower mirror layer, so that the cache generated by the previous build will be used when rebuilding the image. For example, the author needs to use the following files when building a mirror:

As shown in the figure above, the second step and the third step do not rebuild the mirror layer, but use the previous cache. From the fourth step, the mirror layer is rebuilt. When the file size is large and the number of files is large, especially when you need to perform operations such as installation, such a design is still very obvious for the speed of the build. So we should try to choose the Dockerfile method that can use the cache.

to sum up
When you first see the COPY and ADD commands, you can’t help wondering. But after analysis, you will find that the COPY command is designed for the most basic usage, with clear concepts and simple operation. The ADD command is basically a superset of the COPY command (except for the multistage scenario), which allows for some convenient and cool copy operations. The ADD command adds complexity to its use, such as copying compressed files from urls. I hope this article can solve everyone’s doubts about the COPY and ADD commands in the Dockerfile

Docker to build a Tomcat runtime environment

1 Prepare the host system

Prepare a CentOS 7 operating system with the following specific requirements:

Must be a 64-bit operating system. The
kernel is above 3.8 to
view your CentOS kernel with the following command:

# uname -r

2 Install Docker

# yum install docker
Use the following command to see if Docker is installed successfully:

# docker version
If the version number of Docker is output, the installation is successful. You can start the Docker service with the following command:

# systemctl start docker.service
Once the Docker service has started, you can start using Docker.

3 download image

Take CentOS as an example, download a CentOS image:

# docker pull centos After
downloading, use the command to view the local mirror list:

# docker images
centos latest e934aafc2206 2 weeks ago 199MB

4 The host creates the /root/software/ directory and places the installation package in this directory.

5 start the container

The container is run on a mirrored basis. Once the container is started, we can log into the container and install the software or applications we need.

Start the container with the following command:

# docker run -i -t -v /root/software/:/mnt/software/ The e934 /bin/bash
command contains the following three sections:

Docker run <related parameters> <mirror ID> <initial command>
Among them, related parameters include:

-i: indicates
that the container is run in “interactive mode” -t: indicates that the container will enter its command line after startup
-v: indicates which directory needs to be mounted locally to the container, format: -v <host directory>:<container Directory > In
this example, all installers are placed in the /root/software/ directory of the host, and now you need to mount them in the /mnt/software/ directory of the container.

# cd /mnt/software/
# pwd

# ls
apache-tomcat-7.0.81.tar.gz jdk-8u121-linux-x64.tar.gz The
initial command means that once the container is started, you need to run the command. Use “/bin/bash” to indicate that you directly enter the bash shell after booting.

6 Installing the software

In order to build the Java Web runtime environment, you need to install JDK and Tomcat. The following procedures are performed inside the container. In this example, select the /opt/ directory as the installation directory. You must first enter the directory using the cd /opt/ command.

6.1 Installing the JDK

First, unzip the JDK package:

# tar -zxf /mnt/software/jdk-8u121-linux-x64.tar.gz -C .

Then, move the JDK directory:

# mv jdk1.8.0_121/ /opt/jdk/

6.2 Installing Tomcat

First, extract the Tomcat package:

# tar -zxf /mnt/software/apache-tomcat-7.0.81.tar.gz -C .

Then, move the Tomcat directory:

# mv apache-tomcat-7.0.81/ /opt/tomcat/

6.3 Writing a run script

Write a run script that, when the container is started, runs the script and starts Tomcat.

First, create a run script:

# touch /root/run.sh

# vi /root/run.sh
Then, edit the script as follows:


export JAVA_HOME=/opt/jdk/
export PATH=$JAVA_HOME/bin:$PATH

sh /opt/tomcat/bin/catalina.sh run
Finally, add execute permission for running the script:

# chmod u+x /root/run.sh

7 Exit the container

When the above steps are all completed, you can use the exit command to exit the container.

You can then view the running container using the following command:

Docker ps
At this point, you should not see any running programs, because the container that you just exited with the exit command, the container is stopped, you can use the following command to view all containers:

# docker ps -a
d4e3a062ab05 e934 “/bin/bash” 38 minutes ago Exited (0) About a minute ago lucid_einstein
Remember the above CONTAINER ID (container ID), which will then be created through the container One can run a Tomcat image.

8 Create a Tomcat image

Use the following command to create a new “mirror” based on a “container ID”:

# Docker the commit d4e3 mytomcat: 1.0
SHA256: c5ef8dacbf3eead5ea2b9fc3c1050a395863c6db0abd0eb7d6dee8ed46a31ffd

# Docker Images
mytomcat 1.0 c5ef8dacbf3e 18 is seconds The ago Member 583MB
CentOS Latest e934aafc2206 2 weeks ago Member 199MB
ID of this container is d4e3, image name created is “mytomcat: 1.0 “, then you can use the image to start the Tomcat container.

9 Start the Tomcat container

First, create a new /root/webapps/ROOT directory,

Cd # / root
# mkdir webapps
# cd webapps /
# mkdir ROOT
# cd ROOT /
# vi index.html
and create an index.html file in the directory, file reads as follows:

<h2>Hello World!</h2>
As described above, the container can be started with the “mirror name” or “mirror ID”, and the last time it was started. The difference between the containers is that instead of entering the command line of the container, the Tomcat service inside the container is started directly. In this case, you need to use the following command:

# docker run -d -p 58080:8080 -v /root/webapps/:/opt/tomcat/webapps/ –name mytomcat_1 mytomcat:1.0 /root/run.sh
where related parameters include:

-d: Indicates that the /root/run.sh script is executed in “daemon mode”, at which point the Tomcat console does not appear on the output terminal.
-p: indicates the port mapping between the host and the container. At this time, the 8080 port inside the container is mapped to the port 58080 of the host. This exposes the port 58080 to the outside world. The Docker bridge can be used to access the port 8080 inside the container. .
-v: Indicates which local directory needs to be mounted to the container. Format: -v <host directory>: <container directory>
–name: indicates the container name, which can be named with a meaningful name.
In the browser, enter the host IP and port number to access Tomcat:

11 Stop the Tomcat container

# docker ps -a
54215923125b mytomcat:1.0 “/root/run.sh” 3 minutes ago Up 3 minutes>8080/tcp mytomcat_1

# docker stop 5421

12 Remove the container

# docker ps -a
54215923125b mytomcat:1.0 “/root/run.sh” 3 minutes ago Exited (137) 2 seconds ago mytomcat_1

# docker rm 5421

# docker ps -a

13 Remove the image

# Docker Images
mytomcat 1.0 c5ef8dacbf3e 20 is minutes ago Member 583MB
CentOS Latest e934aafc2206 2 weeks ago Member 199MB

# Docker RMI c5ef
the Untagged: mytomcat: 1.0
the Untagged: mytomcat @ SHA256: d949cbb93a58de27eec4c911f27b9f09edeb3d3ce57cf5ce77d4745211c947f6
Deleted: SHA256: c5ef8dacbf3e7ce916f57c52c16de3892c724996b5e30ca0d141c81897d9a06c
Deleted: SHA256: 7e62d1c2f904e8de3fadc6b01edea96bcb324634f0df514cc9297b1bf11d2f06

# Docker images
Centos latest e934aafc2206 2 weeks ago 199MB

IBM MQ 7.5 Developer Edition installation configuration

IBM MQ 7.5 Developer Edition installation configuration

Download the development version here

Download address: https://www.ibm.com/developerworks/cn/downloads/ws/wmq/

Environment CentOS 7.4 x64

1. Preparation before installation

[root@236 ~]# mkdir mq
#Create a new installation directory [root@236 ~]# tar -xzf mqadv_dev75_linux_x86-64.tar.gz -C mq #Unpack
[root@236 ~]# ls mq
copyright MQSeriesFTAgent-7.5. 0-2.x86_64.rpm MQSeriesMan-7.5.0-2.x86_64.rpm MQSeriesMsg_ko-7.5.0-2.x86_64.rpm MQSeriesSDK-7.5.0-2.x86_64.rpm
crtmqpkg MQSeriesFTBase-7.5.0-2.x86_64 .rpm MQSeriesMsg_cs-7.5.0-2.x86_64.rpm MQSeriesMsg_pl-7.5.0-2.x86_64.rpm MQSeriesServer-7.5.0-2.x86_64.rpm
lap MQSeriesFTLogger-7.5.0-2.x86_64.rpm MQSeriesMsg_de-7.5 .0-2.x86_64.rpm MQSeriesMsg_pt-7.5.0-2.x86_64.rpm MQSeriesXRClients-7.5.0-2.x86_64.rpm
licenses MQSeriesFTService-7.5.0-2.x86_64.rpm MQSeriesMsg_es-7.5.0-2.x86_64.rpm MQSeriesMsg_ru-7.5.0-2.x86_64.rpm MQSeriesXRService-7.5.0-2.x86_64.rpm
mqlicense.sh MQSeriesFTTools-7.5.0-2.x86_64.rpm MQSeriesMsg_fr-7.5.0-2.x86_64.rpm MQSeriesMsg_Zh_CN-7.5.0-2.x86_64.rpm PreReqs
MQSeriesAMS-7.5.0-2.x86_64.rpm MQSeriesGSKit-7.5.0-2.x86_64.rpm MQSeriesMsg_hu-7.5.0-2.x86_64.rpm MQSeriesMsg_Zh_TW-7.5.0-2.x86_64.rpm READMEs
MQSeriesClient-7.5.0-2.x86_64.rpm MQSeriesJava-7.5.0-2.x86_64.rpm MQSeriesMsg_it-7.5.0-2.x86_64.rpm MQSeriesRuntime-7.5.0-2.x86_64.rpm repackage
MQSeriesExplorer-7.5.0-2.x86_64.rpm MQSeriesJRE-7.5.0-2.x86_64.rpm MQSeriesMsg_ja-7.5.0-2.x86_64.rpm MQSeriesSamples-7.5.0-2.x86_64.rpm

Run the license, choose 1 to agree


Install MQ Server

[root@236 mq]# rpm -ivh MQSeriesRuntime-7.5.0-2.x86_64.rpm #??MQ Runtime
Preparing… ################################# [100%]
Creating group mqm
Creating user mqm
Updating / installing…
1:MQSeriesRuntime-7.5.0-2 ################################# [100%]

[root@236 mq]# rpm -ivh MQSeriesSamples-7.5.0-2.x86_64.rpm ##??MQ Samples
Preparing… ################################# [100%]
Updating / installing…
1:MQSeriesSamples-7.5.0-2 ################################# [100%]

[root@236 mq]# rpm -ivh MQSeriesServer-7.5.0-2.x86_64.rpm #??MQ server
Preparing… ################################# [100%]
Updating / installing…
1:MQSeriesServer-7.5.0-2 ################################# [100%]

After the installation has completed, run the ‘/opt/mqm/bin/mqconfig’
command, using the ‘mqm’ user ID.

For example, execute the following statement when running as the ‘root’ user:

su mqm -c “/opt/mqm/bin/mqconfig”

The ‘mqconfig’ command validates that the system configuration satisfies the
requirements for WebSphere MQ, and ensures that the settings for the ‘mqm’
user ID are suitably configured. Other WebSphere MQ administrators in the
‘mqm’ group can run this command to ensure their user limits are also
properly configured to use WebSphere MQ.

If ‘mqconfig’ indicates that any of the requirements have not been met,
consult the installation section within the WebSphere MQ Information Center
for details about how to configure the system and user limits.

Then follow the prompts and execute the command to check if the environment is allowed.

First check, prompting for missing bc

[root@236 mq]# su mqm -c “/opt/mqm/bin/mqconfig”
mqconfig: Analyzing CentOS Linux release 7.4.1708 (Core) settings for
WebSphere MQ V7.5
mqconfig: The bc program was not found on this system. Please install bc
and try running mqconfig again.

Install bc

[root@236 mq]# yum install -y bc




Second inspection

There are several fail to resolve, refer to the documentation: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ins.doc/q008550_.htm

Modify kernel parameters

Edit /sysctl.conf and add the following configuration

[root @ 236 mq] # vim /etc/sysctl.conf

kernel.sem = 500 256000 250 1024

net.ipv4.tcp_keepalive_time = 300

fs.file-max = 524288

Write configuration

[root@236 mq]# sysctl -p

Third check

2 files left to be solved

Edit limit.conf

[root @ 236 mq] # vim /etc/security/limits.conf

Add two lines

mqm hard capsule 10240
mqm soft capsule 10240

The fourth inspection passed

Modify environment variables

Since mq is installed in the /opt/mqm directory by default, you will not find the mq related command after the installation is complete. You need to configure the environment variable to find it.

Vim /etc/profile #Add the following line


The installation is complete

2, start the instance

Switch to mqm user startup

[root @ 236 mq] # su mqm
bash-4.2 $

Create a default instance

bash-4.2$ crtmqm -q oe
WebSphere MQ queue manager created.
Directory ‘/var/mqm/qmgrs/oe’ created.
The queue manager is associated with installation ‘Installation1’.
Creating or replacing default objects for queue manager ‘oe’.
Default objects statistics : 74 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.

View the instance, the status is extended

bash-4.2$ dspmq
QMNAME(oe) STATUS(Ended immediately)

Start instance

bash-4.2$ strmqm oe
WebSphere MQ queue manager ‘oe’ starting.
The queue manager is associated with installation ‘Installation1’.
5 log records accessed on queue manager ‘oe’ during the log replay phase.
Log replay for queue manager ‘oe’ complete.
Transaction manager state recovered for queue manager ‘oe’.
WebSphere MQ queue manager ‘oe’ started using V7.5.0.2.


Create a queue named test

bash-4.2$ runmqsc oe
5724-H72 (C) Copyright IBM Corp. 1994, 2011. ALL RIGHTS RESERVED.
Starting MQSC for queue manager oe.

define qlocal(test)
1 : define qlocal(test)
AMQ8006: WebSphere MQ queue created.
2 : end
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Send message test, error 2085

bash-4.2$ amqsput Test oe
Sample AMQSPUT0 start
target queue is Test
MQOPEN ended with reason code 2085
unable to open queue for output
Sample AMQSPUT0 end

Later, I found that the queue could not be lowercase. The test queue was converted to uppercase. It is recommended that the queue name be set to uppercase, resend the message test, and press twice to confirm the input.

bash-4.2$ amqsput TEST oe
Sample AMQSPUT0 start
target queue is TEST
hello world!

Sample AMQSPUT0 end

Receive a message and accept success

bash-4.2$ amqsget TEST oe
Sample AMQSGET0 start
message <hello world!>

Start port listening

bash-4.2$ runmqlsr -t tcp -p 2424 -m oe &
[1] 5067
bash-4.2$ 5724-H72 (C) Copyright IBM Corp. 1994, 2011. ALL RIGHTS RESERVED.

Successful startup

bash-4.2$ netstat -tpln | grep 2424
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp6 0 0 :::2424 :::* LISTEN 5067/runmqlsr


docker centos

[root@ docker]# cat /etc/yum.repos.d/docker-main.repo
name=Docker main Repository

[root@ docker]# yum install docker-engine –y

[root@ docker]# docker –version
Docker version 17.05.0-ce, build 89658be

firewall-cmd –add-port=2377/tcp –permanent

firewall-cmd –add-port=7946/tcp –permanent

firewall-cmd –add-port=7946/udp –permanent

firewall-cmd –add-port=4789/udp –permanent

firewall-cmd –reload**

[root@ docker]# cat /etc/docker/daemon.json

[root@ ~]# systemctl restart docker.service

[root@master ~]# docker swarm join-token worker
To add a worker to this swarm, run the following command:

docker swarm join \
–token SWMTKN-1-4p4djbee1kqcss8x5prfzg6v01x0y7hfa7rqob6rffg6e2p2wq-278qafb9ptpqtfebr0kyngi0b \

[root@filters ~]# docker node ls
0y4ga216x49nd9zt821afe45p * mohan_191_6 Ready Active Reachable
56mgklq3iyf0ajioytmtr0b44 mohan_191_10 Ready Active
b5mljua4e0tchrrk871ggbw7r mohan_191_7 Ready Active Reachable
gxm1gvh8lx2eja36a4cms9w98 mohan_182_212 Ready Active
hgweoxc5vmy9g30uyozmbumhj mohan_182_213 Ready Active
lluom23ugtfuiwphcye2frbmd mohan_182_215 Ready Active
om0ezdbqzdvavn8z8d844osbo mohan_182_214 Ready Active
t00tu1qs7wbll2fg2accsx7wf mohan_191_4 Ready Active Leader
tk89xphvsg16rz7b7l6lam4xv mohan_191_9 Ready Active
xbcx4hx2lq3ji8zog2ayzctat mohan_191_8 Ready Active Reachable
y3pnrw9jt69vkfiuxrs0co7ke mohan_191_5 Ready Active Reachable

docker swarm join –token manger node ip:port

[root@dockernode~]#docker swarm join –token SWMTKN-1-4p4djbee1kqcss8x5prfzg6v01x0y7hfa7rqob6rffg6e2p2wq-278qafb9ptpqtfebr0kyngi0b




$ docker run Ubuntu:14.04 /bin/echo ‘Hello world’
Hello world

$ docker run -t -i ubuntu:14.04 /bin/bash

$ docker run -d ubuntu /bin/sh -c “while true; do echo hello world; sleep 1; done”

$ docker container ls
cb30b87566d0 ubuntu “/bin/sh -c ‘while t…” 2 minutes ago Up 2 minutes goofy_mcclintock

$ docker container logs goofy_mcclintock
hello world
hello world
hello world

$ docker container stop goofy_mcclintock

$ docker container ls -a
cb30b87566d0 ubuntu “/bin/sh -c ‘while t…” 20 minutes ago Exited (137) 23 seconds ago goofy_mcclintock

$ docker attach e1ff

Note: If exit from this stdin, it will cause the container to stop.

The exec command
-i -t parameter
docker exec can be followed by multiple parameters, here mainly the -i -t parameter.
When only the -i parameter, since there is no allocation of pseudo-terminals, the interface is not familiar Linux command prompt, the command execution
line results can still be returned.
When the -i -t parameter is used together, you can see the familiar Linux command prompt.

$ docker run -dit ubuntu

$ docker container ls
16168d4b66b1 ubuntu “/bin/bash” 58 seconds ago Up 57 seconds happy_bardeen

$ docker exec -it 16168 bash

Exit from this stdin will not cause the container to stop. That’s why the docker exec is recommended.
For more parameter descriptions, please use docker exec –help to view.

Fifth, delete the container

Delete a container that is in a terminated state in the format:
docker container rm [options] CONTAINER [CONTAINER…]

$ docker container rm awesome_payne

If you want to delete a running container, you can add the -f parameter. Docker will send a SIGKILL signal to the container.

Clean up all containers in the terminated state. Use the docker container ls -a command to view all the containers that have been created, including the termination status. If the number is too large, it may be cumbersome to delete them one by one. You can use the following command to clear all the termination status. Container.

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:

Export and import containers

Exporting a container
If you want to export a local container, you can use the docker export command.

$ docker container ls -a
16168d4b66b1 ubuntu “/bin/bash” 18 minutes ago Up 18 minutes happy_bardeen

$ docker export 16168d4b66b1 > ubuntu.tar

This will export the container snapshot to a local file.

Import container snapshots
can be imported as mirrors from the container snapshot file using docker import, for example

$ cat ubuntu.tar | docker import – test/ubuntu:v1.0

$ docker image ls
test/ubuntu v1.0 91b174fec9ed 10 seconds ago 69.8MB
ubuntu latest 735f80812f90 3 weeks ago 83.5MB

Alternatively, you can import it by specifying a URL or a directory, such as
$ docker import http://example.com/exampleimage.tgz example/imagerepo

Note: Users can either use the docker load to import the image storage file to the local image library, or use docker import to import a container snapshot to the local image library. The difference between the two is that the container snapshot file will discard all history and metadata information (that is, only the snapshot state of the container at the time), and the image storage file will save the full record and be large. In addition, metadata information such as tags can be reassigned when importing from a container snapshot file.

MySQL: Calculate the free space in IBD files

If you use MySQL with InnoDB, chances are you’ve seen growing IBD data files. Those are the files that actually hold your data within MySQL. By default, they only grow — they don’t shrink. So how do you know if you still have free space left in your IBD files?

There’s a query you can use to determine that:

SELECT round((data_length+index_length)/1024/1024,2)
FROM information_schema.tables
  AND table_name='history_text';

The above will check a database called zabbix for a table called history_text. The result will be the size that MySQL has “in use” in that file. If that returns 5.000 as a value, you have 5GB of data in there.

In my example, it showed the data size to be 16GB. But the actual IBD file was over 50GB large.

$ ls -alh history_text.ibd
-rw-r----- 1 mysql mysql 52G Sep 10 15:26 history_text.ibd

In this example I had 36GB of wasted space on the disk (52GB according to the OS, 16GB in use by MySQL). If you run MySQL with innodb_file_per_table=ON, you can individually shrink the IBD files. One way, is to run an OPTIMIZE query on that table.

Note: this can be a blocking operation, depending on your MySQL version. WRITE and READ I/O can be blocked to the table for the duration of the OPTIMIZE query.

MariaDB [zabbix]> OPTIMIZE TABLE history_text;
Stage: 1 of 1 'altering table'   93.7% of stage done
Stage: 1 of 1 'altering table'    100% of stage done

| Table               | Op       | Msg_type | Msg_text                                                          |
| zabbix.history_text | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| zabbix.history_text | optimize | status   | OK                                                                |
2 rows in set (55 min 37.37 sec)

The result is quite a big file size savings:

$ ls -alh history_text.ibd
-rw-rw---- 1 mysql mysql 11G Sep 10 16:27 history_text.ibd

The file that was previously 52GB in size, is now just 11GB.

Apache 2.4 AH01762 & AH01760: failed to initialize shm (Shared Memory Segment)

Apache 2.4 AH01762 & AH01760: failed to initialize shm (Shared Memory Segment)

Mattias Geniar, Tuesday, January 12, 2016

I recently ran into the following problem on an Apache 2.4 server, where after server reboot the service itself would no longer start.

This was the error whenever I tried to start it:

$ tail -f error.log
[auth_digest:error] [pid 11716] (2)No such file or directory:
   AH01762: Failed to create shared memory segment on file /run/httpd/authdigest_shm.11716
[auth_digest:error] [pid 11716] (2)No such file or directory:
   AH01760: failed to initialize shm - all nonce-count checking, one-time nonces,
   and MD5-sess algorithm disabled

Systemd reported the same problem;

$ systemctl status -l httpd.service
 - httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since ...

The cause is shown in the first error message: Failed to create shared memory segment on file /run/httpd/authdigest_shm.11716.

If I traced this, I noticed the directory /run/httpd no longer existed. The simple fix in this case, was to re-create that missing directory.

$ mkdir /run/httpd
$ chown root:httpd /run/httpd
$ chmod 0710 /run/httpd

The directory should be owned by root and writeable for the root user. The Apache group (in my case, httpd), needs executable rights to look into the directory.


iven facility which allows non-dependent subsystems to be started, controlled, or stopped in parallel. Here we explain how to add a custom script to the systemd facility.

1. Write And Debug The Custom Script

Typically a systemd script is written as a shell script. Begin by writing your custom script using the normal conventions. We will call our script my-custom-script.sh and is straightforward:

echo "I am a custom script" > /var/tmp/script.out
echo "The script was run at : `date`" >> > /var/tmp/script.out

The script must be executable.

# chmod 0755 /var/tmp/my-custom-script.sh

2. Describe The Custom Script To systemd

With the script written and tested manually, the script is ready to be described to the systemd system. To do this, a [name].service file is needed. The syntax uses the INI format commonly used for configuration files. Continuing our example, we need a my-custom-script.service file. The executable will run exactly once for each time the service is started. The service will not be started until the networking layer is up and stable.

Create a new service unit file at /etc/systemd/system/my-custom-script.service with below content. The name of the service unit is user defined and can be any name of your choice.

# This is my-custom-script.service, which describes the my-custom-script.sh file
Description=This is executed on shutdown or reboot
Wants=network-pre.target                                                                   # (if network is required before running the script)
Before=network-pre.target shutdown.target reboot.target halt.target                        # Defines the order in which units are stoped. #(REQUIRED)

Type=oneshot                                                                               # enables specifying multiple custom commands that are then executed sequentially. (REQUIRED)
RemainAfterExit=true                                                                       # required by the oneshot setting (REQUIRED)
Environment=ONE='one' "TWO='2"                                                             # you can set some environment variables, that may be necessary to pass as arguments
ExecStart=/bin/true                                                                        # because is a shutdown script nothing is done when this service is started
ExecStop=/bin/bash /var/tmp/my-custom-script.sh ${ONE} ${TWO}                              # < --*********** change to the script full path ************ (REQUIRED)
TimeoutStopSec=1min 35s                                                                    # Configures the time to wait for stop. 

WantedBy=multi-user.target                                                                 # When this unit is enabled, the units listed in WantedBy gain a Want dependency on the unit. (REQUIRED)

3. Enable The Script For Future Reboots

Similar to the chkconfig from earlier versions, the service must be enabled. Since a new service was added, notify the systemd daemon to reconfigure itself:

# systemctl enable my-custom-script.service
# systemctl daemon-reload

time difference

Time difference

res1=$(date +%s.%N)
sleep 1
res2=$(date +%s.%N)
echo "Start time: $res1"
echo "Stop time:  $res2"
echo "Elapsed:    $(echo "$res2 - $res1"|bc )"

printf "Elapsed:    %.3F\n"  $(echo "$res2 - $res1"|bc )





y default elasticsearch listens to localhost.

# netstat -na|grep LISTEN |grep 9200
tcp6       0      0          :::*                    LISTEN
tcp6       0      0 ::1:9200                :::*                    LISTEN       

If you want to access over the network you need to edit network.host parameter /etc/elasticsearch/elasticsearch.yml  file

———————————- Network ———————————–
# Set the bind address to a specific IP (IPv4 or IPv6):
# Set a custom port for HTTP:
http.port: 9200

Comment out network.host and type your IP address or type to listen all interfaces


and restart elasticsearch

# systemctl restart elasticsearch 


# netstat -na|grep LISTEN |grep 9200
tcp6       0      0 :::9200                 :::*                    LISTEN

  “name” : “Phantom Eagle”,
  “cluster_name” : “elasticsearch”,
  “cluster_uuid” : “k9tOhsoyTrOnvR-QpUpHxA”,
  “version” : {
    “number” : “2.4.1”,
    “build_hash” : “c67dc32e24162035d18d6fe1e952c4cbcbe79d16”,
    “build_timestamp” : “2016-09-27T18:57:55Z”,
    “build_snapshot” : false,
    “lucene_version” : “5.5.2”
  “tagline” : “You Know, for Search”

In this case, your elasticsearch will be accessible from network without any restriction. You should enable IP based filtering/firewall or user authentication.

Hotlink Protection

Enable Hotlink Protection on Apache

If your WordPress site is running on Apache, all you need to do is open the .htaccess file in your site’s root directory (or create it) and add the following:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?bing.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yahoo.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|svg)$ http://dropbox.com/hotlink-placeholder.jpg [NC,R,L]

The second line allows blank referrers. You will most likely want to enable this as some visitors use a personal firewall or antivirus program that deletes the page referrer information sent by the web browser. If you don’t allow blank referrers, you could inadvertently disable all of your images for those users.

The third line defines the allowed referrer, the site that is allowed to link to the image directly, this should be your website (update yourdomain.com above with your domain). The fourth, fifth, and sixth lines add search engines to the allowed list, because you don’t want to block crawlers such as Google bot or Bing bot. This could prevent your images from showing and indexing in Google image search.

And the seventh line defines the image you want the visitor to see in place of the hotlink protected image. This not required, but you could give them a friendly warning. If you want to allow multiple sites you can duplicate this row and replace the referrer. If you want to generate some more complex rules, take a look at this htaccess hotlink protection generator.

If you are using the above rules along with a CDN, you might also need to whitelist your CDN subdomain.

Enable Hotlink Protection on NGINX

If you are running on NGINX, all you need to do is open your config file and add the following:

location ~ .(gif|png|jpeg|jpg|svg)$ {
     valid_referers none blocked ~.google. ~.bing. ~.yahoo. yourdomain.com *.yourdomain.com;
     if ($invalid_referer) {
        return   403;

If you are a Kinsta user and aren’t using a CDN, we can add this for you. Just open up a quick ticket with our support team from the MyKinsta dashboard. If you are using the above rules along with a CDN, you might also need to whitelist your CDN subdomain.

Implementing Content Security Policy in Apache

Header unset Content-Security-Policy
Header add Content-Security-Policy "default-src 'self'"
Header unset X-Content-Security-Policy
Header add X-Content-Security-Policy "default-src 'self'"
Header unset X-WebKit-CSP
Header add X-WebKit-CSP "default-src 'self'"

You may also be interested in adding those headers:

Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "DENY"
Header set Strict-Transport-Security "max-age=631138519; includeSubDomains"




Along with SQL injection attacks, cross-site scripting (XSS) attacks are some of the more common to be used when attacking a website. Cross-site scripting attacks are a kind of hack where the attacker manages to inject a piece of code, normally in the form of Javascript, into a website where it is executed by another user.

Let 100TB give you the tools to execute infrastructure management quickly and efficiently with our secure and monitored virtual servers.

Originally, this just covered the use of fooling a website into loading a javascript file from another website, but these days this can also include other content files or malicious fonts and images that may be executed by either the end user’s computer or on the server itself. The purpose of this form of attack is often to infect other users with malware, gain access to their account information or to gain deeper access to the system when run by an administration account.

Content Security Policy

To help prevent against cross-site scripting attacks, the idea of the Content Security Policy was devised. While the first version of CSP was only published in 2012, it has a history running back to 2004 with attempts to resolve this issue. CSP version 2 is the current version of the standard and is supported by  both Chrome and Firefox, while Safari and edge only support version 1. It works when the web server sends a special header to the web browser identifying that the server implements a content security policy.  Ait then dictates from where the browser should load things like stylesheets, script files, images and fonts. The web browser should then reference this information when loading the HTML code for the site and then fail to load any files that aren’t allowed by the policy.

While this won’t render all XSS style attacks impossible, it will (when implemented well) prevent all XSS attacks involving tricking the browser to load malicious files from external websites. Implementing CSP is as simple as placing a few files of configuration in your web server configuration. When running Apache you can place this code in the virtualhost configuration for your website or in a .htaccess file for the directory your website resides within. For anyone running a website on a dedicated server or VPS then the virtualhost configuration method is recommended whilst the .htaccess file method should only be needed if your website is on shared web hosting.

How To Implement CSP

At this point I’m going to be assuming you know how to edit your virtualhost configuration or create a .htaccess file for this purpose. If not then we’ve previously provided guides explaining both that you could use for reference. So prepare your file and add the following directive:

Header set Content-Secure-Policy "default-src 'self';"

This is about the simplest set-up that you can have and informs the browser that the only content  it should be allowing for your site is content that is loaded from your own domain. The Content-Secure-Policy header can be broken down to a number of directives starting with the directive type and then providing the sources for use with the directive. The default-src directive applies to all forms of content such as images, CSS, Javascript, AJAX requests, Frame contents, fonts and media content. There are separate -src directives for each type of file such as script-src and img-src. A full list of the directive types and their potential source declarations is available at the Content Secure Policy site here: https://content-security-policy.com/

Multiple Directives

Each directive can have numerous sources applied to them and you can use multiple directives in the policy separated by semicolons. This allows for both strict and comprehensive settings for the policy. So let’s imagine a more complex example of a blog that may link to images from across the internet, uses Javascript from it’s own domain, jquery from Google’s CDN and Google analytics and only uses it’s own CSS. This could be handled with a header similar to the below:

Header set Content-Secure-Policy "default-src 'none'; script-src 'self' www.google-analytics.com ajax.googleapis.com; img-src *; style-src 'self';"

By including default-src ‘none’ in the directives the browser would block all external files that aren’t explicitly defined later in the Content-Secure-Policy header. The img-src directive uses an asterisk (*) as its source definition to illustrate that it should allow images to be allowed from any domain. Hopefully, the rest of it should be fairly straight forward.
Once you’ve created your Content-Secure-Policy header you can save your file, and if you’ve included the directive within your virtualhost declaration rather than in a .htaccess file, don’t forget to reload the Apache configuration for your changes to take effect.