j1-template 2021.0.1 → 2021.0.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/assets/data/quicklinks.html +2 -2
- data/assets/themes/j1/adapter/js/j1.js +28 -7
- data/assets/themes/j1/modules/iframeResizer/LICENSE +21 -21
- data/assets/themes/j1/modules/lightbox/LICENSE +22 -22
- data/assets/themes/j1/modules/twemoji/js/LICENSE +21 -21
- data/assets/themes/j1/modules/twemoji/js/picker/LICENSE +21 -21
- data/exe/j1 +2 -0
- data/lib/j1/commands/generate.rb +47 -47
- data/lib/j1/patches/rubygems/eventmachine-1.2.7-x64-mingw32/lib/2.6/fastfilereaderext.so +0 -0
- data/lib/j1/patches/rubygems/eventmachine-1.2.7-x64-mingw32/lib/2.6/rubyeventmachine.so +0 -0
- data/lib/j1/utils/exec.rb +1 -1
- data/lib/j1/version.rb +1 -1
- data/lib/j1_app/j1_auth_manager/commands.rb +1 -1
- data/lib/patches/rubygems/eventmachine-1.2.7-x64-mingw32/lib/2.6/fastfilereaderext.so +0 -0
- data/lib/patches/rubygems/eventmachine-1.2.7-x64-mingw32/lib/2.6/rubyeventmachine.so +0 -0
- data/lib/starter_web/Gemfile +18 -8
- data/lib/starter_web/_config.yml +2 -2
- data/lib/starter_web/_data/modules/defaults/authentication.yml +44 -42
- data/lib/starter_web/_data/modules/themer.yml +0 -95
- data/lib/starter_web/_data/resources.yml +2 -2
- data/lib/starter_web/_includes/attributes.asciidoc +1 -1
- data/lib/starter_web/_includes/documents/licenses/mit.asciidoc +19 -19
- data/lib/starter_web/_includes/tables/jekyll_variables.asciidoc +45 -45
- data/lib/starter_web/_includes/tables/template_variables.asciidoc +46 -46
- data/lib/starter_web/assets/images/modules/icons/d1/scalable/d1.svg +1 -1
- data/lib/starter_web/assets/images/pages/j1_webhooks/uml/auth_mgmr_signin_request_flow.uxf +632 -632
- data/lib/starter_web/assets/images/pages/j1_webhooks/uml/webhook_flow.uxf +648 -648
- data/lib/starter_web/collections/posts/public/featured/_posts/2019-06-01-about-cookies.adoc +198 -198
- data/lib/starter_web/collections/posts/public/featured/_posts/_includes/documents/readme +1 -0
- data/lib/starter_web/collections/posts/public/featured/_posts/_includes/documents/unsplash-badge.asciidoc +31 -31
- data/lib/starter_web/collections/posts/public/series/_posts/_includes/documents/100-docker-using-shared-folders.asciidoc +430 -430
- data/lib/starter_web/collections/posts/public/series/_posts/_includes/tables/debug_variables.asciidoc +47 -48
- data/lib/starter_web/config.ru +23 -24
- data/lib/starter_web/dot.nojekyll +19 -19
- data/lib/starter_web/package.json +46 -40
- data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/documents/300_first_awesome_web.asciidoc +11 -12
- data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/tables/debug_variables.asciidoc +47 -48
- data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/tables/readme +1 -0
- data/lib/starter_web/pages/public/learn/roundtrip/600_lunr.adoc +236 -236
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_bottom_info.asciidoc +14 -14
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_bottom_left_warning.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_bottom_right_danger.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_central_success.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_full_height_left_info.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_full_height_right_success.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_top_info.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_top_left_info.asciidoc +11 -11
- data/lib/starter_web/pages/public/learn/roundtrip/_includes/documents/410_top_right_success.asciidoc +11 -11
- data/lib/starter_web/pages/public/legal/en/eu/cookie.policy.asciidoc +50 -55
- data/lib/starter_web/pages/public/previewer/_includes/documents/licenses/mit.asciidoc +19 -19
- data/lib/starter_web/utilsrv/_defaults/package.json +1 -1
- data/lib/starter_web/utilsrv/package.json +1 -1
- metadata +31 -31
- data/lib/j1_app/j1_auth_manager/views/auth_manager_ui.erb.kapott +0 -234
- data/lib/j1_app/j1_auth_manager/views/auth_manager_ui.new.erb +0 -297
- data/lib/starter_web/_data/modules/defaults/jekyll_search.yml +0 -151
- data/lib/starter_web/_data/modules/jekyll_search.yml +0 -33
@@ -1,430 +1,430 @@
|
|
1
|
-
[[readmore]]
|
2
|
-
== Docker smooth on Windows
|
3
|
-
|
4
|
-
[role="mb-3"]
|
5
|
-
image::{page-imagesdir}/windows_docker_banner.1280x500.png[{{page.title}}]
|
6
|
-
|
7
|
-
In general, two incarnations of Docker for Windows are available:
|
8
|
-
|
9
|
-
* Legacy solution: *Docker Toolbox*
|
10
|
-
* Native solution: *Docker for Windows*
|
11
|
-
|
12
|
-
Before the native version of Docker *Docker for Windows* was available,
|
13
|
-
a *cross-platform* solution called *Docker Toolbox* could be used.
|
14
|
-
*Docker Toolbox* is a bundle of *current* Docker software based on
|
15
|
-
*Docker Machine* combined with the *Docker Engine* bundled with
|
16
|
-
*VirtualBox* as a Hypervisor to run Linux boxes as virtual machines
|
17
|
-
on Windows.
|
18
|
-
|
19
|
-
What the Docker team recomments: Update to the newer package, if possible.
|
20
|
-
This should be discussed, especially for Windows, in more detail ...
|
21
|
-
|
22
|
-
[WARNING]
|
23
|
-
====
|
24
|
-
*The Docker Team mentions the following about Docker Toolbox:*
|
25
|
-
|
26
|
-
Docker Toolbox is for *older Windows* systems (or *Apple MacOS* versions)
|
27
|
-
that *does not meet* the requirements of the *native* Docker version.
|
28
|
-
====
|
29
|
-
|
30
|
-
Docker won't never run *natively* on Windows. The *Container Technology*
|
31
|
-
used by Docker depends on *Linux* (at least on a Unix flavour of the host
|
32
|
-
operating system). For all non-Linux (or Unix) platforms, a *Hypervisor* is
|
33
|
-
needed to make it possible to run the needed *Linux OS* for Docker.
|
34
|
-
|
35
|
-
Yes, Windows support a *native* Hypervisor layer: `Hyper-V`. Using the Windows
|
36
|
-
component `Hyper-V`, any operating system can be run as *virtual machines* on
|
37
|
-
Windows. But it should be kept in mind: the Hypervisor layer is *always* needed;
|
38
|
-
as well as for the so-called the *native* Docker version on Windows. But:
|
39
|
-
real *native* Docker versions does *not* need a Hypervisor layer; they run
|
40
|
-
containers direcly on the host OS! This should be kept on mind.
|
41
|
-
|
42
|
-
They are some pittfals using *Docker for Windows* if you go for:
|
43
|
-
|
44
|
-
* Stability - found quite often issues running containers on *Docker for Windows*.
|
45
|
-
If you're not a Windows specialist, it is hard to findout issues for `Hyper-V`
|
46
|
-
, the VM and|or both.
|
47
|
-
* Flexibility - it is *NOT* possible to use the Hypervisor `Hyper-V` in
|
48
|
-
parallel to *VirtualBox* as an alternative
|
49
|
-
* Incompatibility - on some Windows installations, and for sure they met the
|
50
|
-
requirements of the *native* Docker version, the installaton was *NOT*
|
51
|
-
successful and Docker fails to start
|
52
|
-
|
53
|
-
Again: the software included in the *Docker Toolbox* are *current* versions.
|
54
|
-
The latest Toolbox contains:
|
55
|
-
|
56
|
-
* the Docker Engine Docker, version 18.03.0-ce, build 0520e24302
|
57
|
-
* the Docker Machine, version 0.14.0, build 89b8332
|
58
|
-
* the Docker Composer, version 1.20.1, build 5d8c71b2
|
59
|
-
* a current MINGW64-based GNU bash, version 4.4.19(2)-release (x86_64-pc-msys)
|
60
|
-
|
61
|
-
For all the people having their (IT) roots on Unix respectively Linux, the
|
62
|
-
*Docker Toolbox* is the better solution on Windows (for now). No need to go
|
63
|
-
for the Windows Hypervisor `Hyper-V` - Oracle *VirtualBox* can be used
|
64
|
-
instead; as quite often used for testing and development.
|
65
|
-
|
66
|
-
Let's have a look how to *Manage Linux on Windows*, to use Docker on the
|
67
|
-
Windows platform.
|
68
|
-
|
69
|
-
== Installing Docker Toolbox
|
70
|
-
|
71
|
-
As discussed ealier, *Docker Toolbox* is using *VirtualBox* for the
|
72
|
-
Hypervisor to create the Linux VMs needed. To get the latest version,
|
73
|
-
install VirtualBox first (Docker Toolbox includes a installer package
|
74
|
-
for VBox but not nessesarily at their latets version).
|
75
|
-
|
76
|
-
Go for the link:{virtualbox-install-on-windows}[VirtualBox Download Page]
|
77
|
-
and select under *VirtualBox 5.x.y platform packages* the latest version
|
78
|
-
for Windows (Windows hosts). Install the package - the installation process
|
79
|
-
is quite simple supported by an build in installer wizard.
|
80
|
-
|
81
|
-
If done, go for the installation of the Toolbox. A current package can be
|
82
|
-
retrieved from link:{docker-install-toolbox-on-windows}[Docker Documents].
|
83
|
-
The page includes all the info needed to install the software.
|
84
|
-
|
85
|
-
NOTE: For the installation of the *Docker Toolbox*, please deselect the
|
86
|
-
installation of *VirtualBox* included as the software has been already
|
87
|
-
installed.
|
88
|
-
|
89
|
-
NOTE: The commandline interface used by *Docker Toolbox* is based on
|
90
|
-
*Git MSYS-git UNIX tools*. If you have *Git* installed already for your
|
91
|
-
Windows host, please deselect the installation of *Git* included.
|
92
|
-
|
93
|
-
*Docker Toolbox* comes with *NO* graphical user interface (GUI). To manage
|
94
|
-
Docker, the included GNU bash of the *Git MSYS-git UNIX tools* shoud be used.
|
95
|
-
A very first version of a (native) Docker UI on Windows is *Kitematic*,
|
96
|
-
currently in a alpha version included.
|
97
|
-
|
98
|
-
ifdef::backend-html5[]
|
99
|
-
.Docker UI Kinematic on Windows
|
100
|
-
lightbox::docker-windows-kinematic-alpha[ 800, {docker-windows-kinematic-alpha-data} ]
|
101
|
-
endif::[]
|
102
|
-
|
103
|
-
TIP: You should check *Kitematic*. If started for *Docker Toolbox* on Windows,
|
104
|
-
change (the Hypervisor) to Virtualbox.
|
105
|
-
|
106
|
-
For Windows users a commandline interface to manage a complex system like
|
107
|
-
Docker may sound a bit stone age. It's not for good reasons:
|
108
|
-
|
109
|
-
* the knowlegde of the base Docker commands is essential to understand the
|
110
|
-
Container Technology better
|
111
|
-
|
112
|
-
* Blalal blaaa
|
113
|
-
|
114
|
-
|
115
|
-
|
116
|
-
== Manage Linux on Windows
|
117
|
-
|
118
|
-
VirtualBox is a greate piece of software for desktop and workstation
|
119
|
-
virtualization. A huge number of IT specialist and developers are using VB
|
120
|
-
for: testing and development environments. Sometimes for production
|
121
|
-
environments – if it's applicable.
|
122
|
-
|
123
|
-
One good idea for VirtualBox is, if you are Web|App developer for Linux you
|
124
|
-
can keep *Windows* as your primary OS - yeah, yeah those people are living on
|
125
|
-
our planet! One can install a Linux distribution of choice in VirtualBox VM
|
126
|
-
and reap both benefits of Windows as primary OS and Linux as a server
|
127
|
-
platform for good reasons.
|
128
|
-
|
129
|
-
=== Create a Linux VM
|
130
|
-
|
131
|
-
lorem:sentences[5]
|
132
|
-
|
133
|
-
lorem:sentences[3]
|
134
|
-
|
135
|
-
|
136
|
-
=== Sharing Data
|
137
|
-
|
138
|
-
For (real) native Docker installations, it is easy to share data between then
|
139
|
-
host OS and containers managed by Docker. It is simple this:
|
140
|
-
|
141
|
-
[source, sh]
|
142
|
-
----
|
143
|
-
docker run --rm \
|
144
|
-
--volume=$PWD:/srv/jekyll \
|
145
|
-
-p 35729:35729 -p 40000:40000 \
|
146
|
-
-it jekyll-one/j1:latest \
|
147
|
-
j1 serve --incremental --livereload
|
148
|
-
----
|
149
|
-
|
150
|
-
The container, instructed by `--volume=$PWD:/srv/jekyll` shares the
|
151
|
-
filesystem of the host - the *native* way to bring in data into a
|
152
|
-
container for processing. In the example a static Jekyll Web is created
|
153
|
-
by J1 Template (j1), served by the ports 35729 for livereload and 40000
|
154
|
-
serving the web.
|
155
|
-
|
156
|
-
For the Windows platform, using a virtual Linux Box for Docker containers,
|
157
|
-
this is *NOT* possible. The virtual system is managed by Virtualbox and no
|
158
|
-
direct relationship is in between the VBox and the host operating system
|
159
|
-
Windows! No (direct) access to the host filesystem is possible. Bad luck so
|
160
|
-
far.
|
161
|
-
|
162
|
-
Generally spoken, there are 3 ways of sharing files between a Windows host
|
163
|
-
and Linux guest boxes; keep files:
|
164
|
-
|
165
|
-
* in the guest (Linux) and share them with host through Samba
|
166
|
-
* on host (Windows) and use VirtualBox *Shared Folders*
|
167
|
-
* on host (Windows) and mount Windows *Public Folders* via CIFS
|
168
|
-
from within guest (Linux)
|
169
|
-
|
170
|
-
For all people experienced on the Linux platform, the first option is
|
171
|
-
probably the easiest. But it has it’s drawbacks. In most cases for testing,
|
172
|
-
it's *NOT* wanted to keep files in a VM. In case of corruption of the VM,
|
173
|
-
reinstallation needs, or whatever yor data is *lost* in most cases. Truly,
|
174
|
-
not an option.
|
175
|
-
|
176
|
-
Typically developers want them kept on native Windows *disks* as they are
|
177
|
-
expected as more safely stored on physical devices and easier to backup.
|
178
|
-
So first option is clearly out.
|
179
|
-
|
180
|
-
*Shared Folders* are really a great idea. After installing the *VirtualBox
|
181
|
-
Guest Additions* (which brings the mount.vboxsf binary and vboxsf kernel
|
182
|
-
module) the guest can mount automatically a Windows OS folder inside the VM.
|
183
|
-
Some klicks further the guest start's, mount the *shared folder* in guest and
|
184
|
-
voila: you're done! Sounds really great.
|
185
|
-
|
186
|
-
But there's a catch – performance. Shared Folders are really, really horrible
|
187
|
-
slow. Which in turn kills the idea of programming and testing code without
|
188
|
-
loosing hair because of the slowness. You can find tons of articles around
|
189
|
-
slow shared folders on the Internet; both for the Big Dogs: VMware and
|
190
|
-
VirtualBox. But no solution. Since decades.
|
191
|
-
|
192
|
-
Analyzing the performance, it's obvious that kernel spends really large
|
193
|
-
amount of time in IO mode – so the vboxsf CIFS emulation of VirtualBoxis
|
194
|
-
behaving something like a slug. Birds love slugs but IT professionals don’t
|
195
|
-
like that, do they?
|
196
|
-
|
197
|
-
It seems that the only viable solution is sharing folders though Windows and
|
198
|
-
mounting them via CIFS on the guest, the virtual Linux box. This way, a
|
199
|
-
similiar flexible solution for sharing folders can be achived but at a much
|
200
|
-
better performance.
|
201
|
-
|
202
|
-
|
203
|
-
=== Performance tests
|
204
|
-
|
205
|
-
Anyway, *shared folders* will be always slow as the are of type *NAS* - network
|
206
|
-
attached storage. For a local network nowadays, typically at Gigabit level and
|
207
|
-
quite low in latency, an acceptable performance cab be achived.
|
208
|
-
|
209
|
-
I did some simple tests to show the performance differences. There are three
|
210
|
-
directories I did for my tests:
|
211
|
-
|
212
|
-
* /mnt/media/repo1, data on a physical (local) disk on the host
|
213
|
-
* /mnt/media/repo2, data on a physical (local) disk in the guest
|
214
|
-
* /mnt/media/repo3, data on a Windows share mounted via cifs in the guest
|
215
|
-
|
216
|
-
I've been using simple (bash) script based on *dd* commands for testing.
|
217
|
-
The *dd* commands used as a base are shown below. For sure not a quite
|
218
|
-
sophisticated test scenario but it's giving a general impression what can
|
219
|
-
achived in real world.
|
220
|
-
|
221
|
-
NOTE: For multi-platform testing, on Windows the `dd` command is used as well.
|
222
|
-
For *Docker Toolbox*, beside the GNU bash, a full set of *GNU CoreUtils* are
|
223
|
-
available as well (accessible out of the *Docker Quickstart Terminal*). The
|
224
|
-
used (bash) test script needs to be run out of *Docker Quickstart Terminal*.
|
225
|
-
Download the tester script from here.
|
226
|
-
|
227
|
-
The test script *docker_perf_test.sh* supports a test scenario for
|
228
|
-
*General System Performance*. This is focussing on pure CPU|Memory power.
|
229
|
-
On both systems (host and guest) these tests are using pure *kernel services*
|
230
|
-
for creating input and output data. One is creating random input data as
|
231
|
-
fast as possible, the other discards everything it gets as fast as it can.
|
232
|
-
|
233
|
-
.General System Performance
|
234
|
-
[source, sh]
|
235
|
-
----
|
236
|
-
dd if=/dev/urandom of=/dev/null bs=1M count=10000
|
237
|
-
----
|
238
|
-
|
239
|
-
Please see those tests for *General System Performance* for the background
|
240
|
-
*What could be achived in therory*. These tests may helpful to compare your
|
241
|
-
current setup for the host and the guest same way.
|
242
|
-
|
243
|
-
As mentioned, all tests for *docker_perf_test.sh* are based on the `dd`
|
244
|
-
command. For *real world* measures, standard *dd tests* are used. You'll
|
245
|
-
find a lot of those on the Internet. All tests for *docker_perf_test.sh* are
|
246
|
-
changed (from `/dev/zero`) to `/dev/urandom` for the input to put some
|
247
|
-
*pressure* on the CPU while processing data for reading or writing from the
|
248
|
-
filesystem to be checked. All the tests are *rules of thumb*, no technical
|
249
|
-
measures.
|
250
|
-
|
251
|
-
NOTE: Zum Messen der Schreibperformance liest man die zu Schreibenden
|
252
|
-
Daten am besten aus /dev/zero und schreibt eine normale Datei im Filesystem
|
253
|
-
(z.B. mit of=/root/testfile). Die folgenden Beispiele verwenden ein Testdatei,
|
254
|
-
um irrtümlichen Datenverlust zu vermeiden. Die dabei erzielbare Performance
|
255
|
-
Werte sind etwas geringer (da dadurch auch Metadaten im Filesystem geschrieben
|
256
|
-
werden).
|
257
|
-
|
258
|
-
Find the base `dd` commands for read an write performance tests below. The
|
259
|
-
exported shared folder on Windows is *C:\Users\Public* mapped to the Unix
|
260
|
-
(POSIX) folder scheme of */c/Users/Public* on the guest OS.
|
261
|
-
|
262
|
-
.Write Performance - Windows host (local disk), Linux guest (shared disk)
|
263
|
-
[source, sh]
|
264
|
-
----
|
265
|
-
dd if=/dev/urandom bs=1M count=1024 | split -b 1M - name.
|
266
|
-
----
|
267
|
-
.Write Performance (local disk), Linux guest
|
268
|
-
[source, sh]
|
269
|
-
----
|
270
|
-
dd if=/dev/urandom of=/var/tmp/test/samplefile bs=1M count=1024
|
271
|
-
----
|
272
|
-
|
273
|
-
.Read Performance - Windows host (local disk), Linux guest (shared disk)
|
274
|
-
[source, sh]
|
275
|
-
----
|
276
|
-
dd if=/c/Users/Public/test/samplefile of=/dev/null bs=1M count=1024 iflag=direct
|
277
|
-
----
|
278
|
-
.Read Performance (local disk), Linux guest
|
279
|
-
[source, sh]
|
280
|
-
----
|
281
|
-
dd if=/var/tmp/test/samplefile of=/dev/null bs=1M count=1024 iflag=direct
|
282
|
-
----
|
283
|
-
|
284
|
-
Have a look at the table below for the measures found on a *Windows 10*
|
285
|
-
desktop host (Intel Core Quad Q9550) using a *SATA-300* disk for the local
|
286
|
-
physical disk and a Gigabit network interface (*Realtek PCIe GBE* familiy)
|
287
|
-
running a *CentOS 7 Linux* (version 3.10.0-862) as a guest:
|
288
|
-
|
289
|
-
.Data transfer rates for 1 GB of data
|
290
|
-
[cols="2,2,4,3, options="header", role="table-responsive, full-width"]
|
291
|
-
|===============================================================================
|
292
|
-
|direction |mountpoint |source |througput [MB/s]
|
293
|
-
|
294
|
-
|`read`
|
295
|
-
|/mnt/media/repo1
|
296
|
-
|physical (local) disk on the *host*
|
297
|
-
|85.20
|
298
|
-
|
299
|
-
|`read`
|
300
|
-
|/mnt/media/repo2
|
301
|
-
|physical (local) disk on the *guest*
|
302
|
-
|147.00
|
303
|
-
|
304
|
-
|`read`
|
305
|
-
|/mnt/media/repo3
|
306
|
-
|shared disk on the *guest*
|
307
|
-
|30.3
|
308
|
-
|
309
|
-
|`write`
|
310
|
-
|/mnt/media/repo1
|
311
|
-
|physical (local) disk on the *host*
|
312
|
-
|234.00
|
313
|
-
|
314
|
-
|`write`
|
315
|
-
|/mnt/media/repo2
|
316
|
-
|physical (local) disk on the *guest*
|
317
|
-
|34.00
|
318
|
-
|
319
|
-
|`write`
|
320
|
-
|/mnt/media/repo3
|
321
|
-
|shared disk on the *guest*
|
322
|
-
|39.9
|
323
|
-
|
324
|
-
|===============================================================================
|
325
|
-
|
326
|
-
WARNING: Bei Verwendung von if=/dev/zero und bs=1G benötigt das Linuxsystem
|
327
|
-
1GB freien Platz im RAM. Falls Ihr Testsystem nicht ausreichend RAM ...
|
328
|
-
|
329
|
-
NOTE: Um praxisnahe Ergebnisse zu erhalten empfehlen wir die beschrieben Tests
|
330
|
-
mehrmals (z.B. 3 bis 10x) durchzuführen. Damit können Sie Ausreißer rechtzeitig
|
331
|
-
erkennen.
|
332
|
-
|
333
|
-
|
334
|
-
lorem:sentences[5]
|
335
|
-
|
336
|
-
== Publish a Shared Folder
|
337
|
-
|
338
|
-
lorem:sentences[5]
|
339
|
-
|
340
|
-
lorem:sentences[3]
|
341
|
-
|
342
|
-
|
343
|
-
== Mount Shared Folders on Linux
|
344
|
-
|
345
|
-
lorem:sentences[5]
|
346
|
-
|
347
|
-
=== Installing CIFS
|
348
|
-
|
349
|
-
For the Linux VM, a current Ubunt Server of version 18.06 is used. To mount
|
350
|
-
CIFS shares, the package `cifs-utils` needs to be installed:
|
351
|
-
|
352
|
-
[source, bash]
|
353
|
-
----
|
354
|
-
sudo apt-get -y install cifs-utils
|
355
|
-
----
|
356
|
-
|
357
|
-
Mounting filesystems in general, therefor the same to the CIFS share, are
|
358
|
-
done as root. This ends up in the situation this folder cannot (accessed??)
|
359
|
-
written as normal user.
|
360
|
-
|
361
|
-
. Create the `cifs` group
|
362
|
-
+
|
363
|
-
[source, bash]
|
364
|
-
----
|
365
|
-
sudo groupadd cifs
|
366
|
-
----
|
367
|
-
|
368
|
-
[start=2]
|
369
|
-
. Add your user to the `cifs` group
|
370
|
-
+
|
371
|
-
[source, bash]
|
372
|
-
----
|
373
|
-
sudo usermod -aG cifs $USER
|
374
|
-
----
|
375
|
-
|
376
|
-
[start=3]
|
377
|
-
. Create the mountpoint (to be used by Docker) as root
|
378
|
-
+
|
379
|
-
[source, bash]
|
380
|
-
----
|
381
|
-
mkdir -p /c/Users/Public
|
382
|
-
----
|
383
|
-
|
384
|
-
[start=4]
|
385
|
-
. Change the ownership of the mountpoint
|
386
|
-
+
|
387
|
-
[source, bash]
|
388
|
-
----
|
389
|
-
chown -R root:cifs /c/Users/Public
|
390
|
-
----
|
391
|
-
|
392
|
-
[start=5]
|
393
|
-
. Create a credentials file to place user|password data safe.
|
394
|
-
+
|
395
|
-
[source, bash]
|
396
|
-
----
|
397
|
-
touch ~/.smbcredentials
|
398
|
-
----
|
399
|
-
|
400
|
-
.smbcredentials
|
401
|
-
----
|
402
|
-
username=<your_windows_user>
|
403
|
-
password=<windows_user_password>
|
404
|
-
----
|
405
|
-
|
406
|
-
=== Mount the share manually
|
407
|
-
|
408
|
-
To enable non-authorized users to read and write the shared files, specify
|
409
|
-
user and group ID that the mounted shares folders should use. This would
|
410
|
-
allow particular users and group members to read|write to the share.
|
411
|
-
|
412
|
-
To do so, the following options are used for a public mount:
|
413
|
-
|
414
|
-
* username
|
415
|
-
* password
|
416
|
-
* uid
|
417
|
-
* gid
|
418
|
-
|
419
|
-
Add the Windows host IP address to the hosts file
|
420
|
-
|
421
|
-
./etc/hosts
|
422
|
-
<ip_v4_address> <name_of_the windows_box> <alias_name>
|
423
|
-
|
424
|
-
|
425
|
-
=== Mount the share at boot-time
|
426
|
-
|
427
|
-
lorem:sentences[3]
|
428
|
-
|
429
|
-
./etc/fstab
|
430
|
-
//win10pc/Public /c/Users/Public cifs uid=1000,gid=5555,credentials=/home/jadams/.smbcredentials,iocharset=utf8,rw 0 0
|
1
|
+
[[readmore]]
|
2
|
+
== Docker smooth on Windows
|
3
|
+
|
4
|
+
[role="mb-3"]
|
5
|
+
image::{page-imagesdir}/windows_docker_banner.1280x500.png[{{page.title}}]
|
6
|
+
|
7
|
+
In general, two incarnations of Docker for Windows are available:
|
8
|
+
|
9
|
+
* Legacy solution: *Docker Toolbox*
|
10
|
+
* Native solution: *Docker for Windows*
|
11
|
+
|
12
|
+
Before the native version of Docker *Docker for Windows* was available,
|
13
|
+
a *cross-platform* solution called *Docker Toolbox* could be used.
|
14
|
+
*Docker Toolbox* is a bundle of *current* Docker software based on
|
15
|
+
*Docker Machine* combined with the *Docker Engine* bundled with
|
16
|
+
*VirtualBox* as a Hypervisor to run Linux boxes as virtual machines
|
17
|
+
on Windows.
|
18
|
+
|
19
|
+
What the Docker team recomments: Update to the newer package, if possible.
|
20
|
+
This should be discussed, especially for Windows, in more detail ...
|
21
|
+
|
22
|
+
[WARNING]
|
23
|
+
====
|
24
|
+
*The Docker Team mentions the following about Docker Toolbox:*
|
25
|
+
|
26
|
+
Docker Toolbox is for *older Windows* systems (or *Apple MacOS* versions)
|
27
|
+
that *does not meet* the requirements of the *native* Docker version.
|
28
|
+
====
|
29
|
+
|
30
|
+
Docker won't never run *natively* on Windows. The *Container Technology*
|
31
|
+
used by Docker depends on *Linux* (at least on a Unix flavour of the host
|
32
|
+
operating system). For all non-Linux (or Unix) platforms, a *Hypervisor* is
|
33
|
+
needed to make it possible to run the needed *Linux OS* for Docker.
|
34
|
+
|
35
|
+
Yes, Windows support a *native* Hypervisor layer: `Hyper-V`. Using the Windows
|
36
|
+
component `Hyper-V`, any operating system can be run as *virtual machines* on
|
37
|
+
Windows. But it should be kept in mind: the Hypervisor layer is *always* needed;
|
38
|
+
as well as for the so-called the *native* Docker version on Windows. But:
|
39
|
+
real *native* Docker versions does *not* need a Hypervisor layer; they run
|
40
|
+
containers direcly on the host OS! This should be kept on mind.
|
41
|
+
|
42
|
+
They are some pittfals using *Docker for Windows* if you go for:
|
43
|
+
|
44
|
+
* Stability - found quite often issues running containers on *Docker for Windows*.
|
45
|
+
If you're not a Windows specialist, it is hard to findout issues for `Hyper-V`
|
46
|
+
, the VM and|or both.
|
47
|
+
* Flexibility - it is *NOT* possible to use the Hypervisor `Hyper-V` in
|
48
|
+
parallel to *VirtualBox* as an alternative
|
49
|
+
* Incompatibility - on some Windows installations, and for sure they met the
|
50
|
+
requirements of the *native* Docker version, the installaton was *NOT*
|
51
|
+
successful and Docker fails to start
|
52
|
+
|
53
|
+
Again: the software included in the *Docker Toolbox* are *current* versions.
|
54
|
+
The latest Toolbox contains:
|
55
|
+
|
56
|
+
* the Docker Engine Docker, version 18.03.0-ce, build 0520e24302
|
57
|
+
* the Docker Machine, version 0.14.0, build 89b8332
|
58
|
+
* the Docker Composer, version 1.20.1, build 5d8c71b2
|
59
|
+
* a current MINGW64-based GNU bash, version 4.4.19(2)-release (x86_64-pc-msys)
|
60
|
+
|
61
|
+
For all the people having their (IT) roots on Unix respectively Linux, the
|
62
|
+
*Docker Toolbox* is the better solution on Windows (for now). No need to go
|
63
|
+
for the Windows Hypervisor `Hyper-V` - Oracle *VirtualBox* can be used
|
64
|
+
instead; as quite often used for testing and development.
|
65
|
+
|
66
|
+
Let's have a look how to *Manage Linux on Windows*, to use Docker on the
|
67
|
+
Windows platform.
|
68
|
+
|
69
|
+
== Installing Docker Toolbox
|
70
|
+
|
71
|
+
As discussed ealier, *Docker Toolbox* is using *VirtualBox* for the
|
72
|
+
Hypervisor to create the Linux VMs needed. To get the latest version,
|
73
|
+
install VirtualBox first (Docker Toolbox includes a installer package
|
74
|
+
for VBox but not nessesarily at their latets version).
|
75
|
+
|
76
|
+
Go for the link:{virtualbox-install-on-windows}[VirtualBox Download Page]
|
77
|
+
and select under *VirtualBox 5.x.y platform packages* the latest version
|
78
|
+
for Windows (Windows hosts). Install the package - the installation process
|
79
|
+
is quite simple supported by an build in installer wizard.
|
80
|
+
|
81
|
+
If done, go for the installation of the Toolbox. A current package can be
|
82
|
+
retrieved from link:{docker-install-toolbox-on-windows}[Docker Documents].
|
83
|
+
The page includes all the info needed to install the software.
|
84
|
+
|
85
|
+
NOTE: For the installation of the *Docker Toolbox*, please deselect the
|
86
|
+
installation of *VirtualBox* included as the software has been already
|
87
|
+
installed.
|
88
|
+
|
89
|
+
NOTE: The commandline interface used by *Docker Toolbox* is based on
|
90
|
+
*Git MSYS-git UNIX tools*. If you have *Git* installed already for your
|
91
|
+
Windows host, please deselect the installation of *Git* included.
|
92
|
+
|
93
|
+
*Docker Toolbox* comes with *NO* graphical user interface (GUI). To manage
|
94
|
+
Docker, the included GNU bash of the *Git MSYS-git UNIX tools* shoud be used.
|
95
|
+
A very first version of a (native) Docker UI on Windows is *Kitematic*,
|
96
|
+
currently in a alpha version included.
|
97
|
+
|
98
|
+
ifdef::backend-html5[]
|
99
|
+
.Docker UI Kinematic on Windows
|
100
|
+
lightbox::docker-windows-kinematic-alpha[ 800, {docker-windows-kinematic-alpha-data} ]
|
101
|
+
endif::[]
|
102
|
+
|
103
|
+
TIP: You should check *Kitematic*. If started for *Docker Toolbox* on Windows,
|
104
|
+
change (the Hypervisor) to Virtualbox.
|
105
|
+
|
106
|
+
For Windows users a commandline interface to manage a complex system like
|
107
|
+
Docker may sound a bit stone age. It's not for good reasons:
|
108
|
+
|
109
|
+
* the knowlegde of the base Docker commands is essential to understand the
|
110
|
+
Container Technology better
|
111
|
+
|
112
|
+
* Blalal blaaa
|
113
|
+
|
114
|
+
|
115
|
+
|
116
|
+
== Manage Linux on Windows
|
117
|
+
|
118
|
+
VirtualBox is a greate piece of software for desktop and workstation
|
119
|
+
virtualization. A huge number of IT specialist and developers are using VB
|
120
|
+
for: testing and development environments. Sometimes for production
|
121
|
+
environments – if it's applicable.
|
122
|
+
|
123
|
+
One good idea for VirtualBox is, if you are Web|App developer for Linux you
|
124
|
+
can keep *Windows* as your primary OS - yeah, yeah those people are living on
|
125
|
+
our planet! One can install a Linux distribution of choice in VirtualBox VM
|
126
|
+
and reap both benefits of Windows as primary OS and Linux as a server
|
127
|
+
platform for good reasons.
|
128
|
+
|
129
|
+
=== Create a Linux VM
|
130
|
+
|
131
|
+
lorem:sentences[5]
|
132
|
+
|
133
|
+
lorem:sentences[3]
|
134
|
+
|
135
|
+
|
136
|
+
=== Sharing Data
|
137
|
+
|
138
|
+
For (real) native Docker installations, it is easy to share data between then
|
139
|
+
host OS and containers managed by Docker. It is simple this:
|
140
|
+
|
141
|
+
[source, sh]
|
142
|
+
----
|
143
|
+
docker run --rm \
|
144
|
+
--volume=$PWD:/srv/jekyll \
|
145
|
+
-p 35729:35729 -p 40000:40000 \
|
146
|
+
-it jekyll-one/j1:latest \
|
147
|
+
j1 serve --incremental --livereload
|
148
|
+
----
|
149
|
+
|
150
|
+
The container, instructed by `--volume=$PWD:/srv/jekyll` shares the
|
151
|
+
filesystem of the host - the *native* way to bring in data into a
|
152
|
+
container for processing. In the example a static Jekyll Web is created
|
153
|
+
by J1 Template (j1), served by the ports 35729 for livereload and 40000
|
154
|
+
serving the web.
|
155
|
+
|
156
|
+
For the Windows platform, using a virtual Linux Box for Docker containers,
|
157
|
+
this is *NOT* possible. The virtual system is managed by Virtualbox and no
|
158
|
+
direct relationship is in between the VBox and the host operating system
|
159
|
+
Windows! No (direct) access to the host filesystem is possible. Bad luck so
|
160
|
+
far.
|
161
|
+
|
162
|
+
Generally spoken, there are 3 ways of sharing files between a Windows host
|
163
|
+
and Linux guest boxes; keep files:
|
164
|
+
|
165
|
+
* in the guest (Linux) and share them with host through Samba
|
166
|
+
* on host (Windows) and use VirtualBox *Shared Folders*
|
167
|
+
* on host (Windows) and mount Windows *Public Folders* via CIFS
|
168
|
+
from within guest (Linux)
|
169
|
+
|
170
|
+
For all people experienced on the Linux platform, the first option is
|
171
|
+
probably the easiest. But it has it’s drawbacks. In most cases for testing,
|
172
|
+
it's *NOT* wanted to keep files in a VM. In case of corruption of the VM,
|
173
|
+
reinstallation needs, or whatever yor data is *lost* in most cases. Truly,
|
174
|
+
not an option.
|
175
|
+
|
176
|
+
Typically developers want them kept on native Windows *disks* as they are
|
177
|
+
expected as more safely stored on physical devices and easier to backup.
|
178
|
+
So first option is clearly out.
|
179
|
+
|
180
|
+
*Shared Folders* are really a great idea. After installing the *VirtualBox
|
181
|
+
Guest Additions* (which brings the mount.vboxsf binary and vboxsf kernel
|
182
|
+
module) the guest can mount automatically a Windows OS folder inside the VM.
|
183
|
+
Some klicks further the guest start's, mount the *shared folder* in guest and
|
184
|
+
voila: you're done! Sounds really great.
|
185
|
+
|
186
|
+
But there's a catch – performance. Shared Folders are really, really horrible
|
187
|
+
slow. Which in turn kills the idea of programming and testing code without
|
188
|
+
loosing hair because of the slowness. You can find tons of articles around
|
189
|
+
slow shared folders on the Internet; both for the Big Dogs: VMware and
|
190
|
+
VirtualBox. But no solution. Since decades.
|
191
|
+
|
192
|
+
Analyzing the performance, it's obvious that kernel spends really large
|
193
|
+
amount of time in IO mode – so the vboxsf CIFS emulation of VirtualBoxis
|
194
|
+
behaving something like a slug. Birds love slugs but IT professionals don’t
|
195
|
+
like that, do they?
|
196
|
+
|
197
|
+
It seems that the only viable solution is sharing folders though Windows and
|
198
|
+
mounting them via CIFS on the guest, the virtual Linux box. This way, a
|
199
|
+
similiar flexible solution for sharing folders can be achived but at a much
|
200
|
+
better performance.
|
201
|
+
|
202
|
+
|
203
|
+
=== Performance tests
|
204
|
+
|
205
|
+
Anyway, *shared folders* will be always slow as the are of type *NAS* - network
|
206
|
+
attached storage. For a local network nowadays, typically at Gigabit level and
|
207
|
+
quite low in latency, an acceptable performance cab be achived.
|
208
|
+
|
209
|
+
I did some simple tests to show the performance differences. There are three
|
210
|
+
directories I did for my tests:
|
211
|
+
|
212
|
+
* /mnt/media/repo1, data on a physical (local) disk on the host
|
213
|
+
* /mnt/media/repo2, data on a physical (local) disk in the guest
|
214
|
+
* /mnt/media/repo3, data on a Windows share mounted via cifs in the guest
|
215
|
+
|
216
|
+
I've been using simple (bash) script based on *dd* commands for testing.
|
217
|
+
The *dd* commands used as a base are shown below. For sure not a quite
|
218
|
+
sophisticated test scenario but it's giving a general impression what can
|
219
|
+
achived in real world.
|
220
|
+
|
221
|
+
NOTE: For multi-platform testing, on Windows the `dd` command is used as well.
|
222
|
+
For *Docker Toolbox*, beside the GNU bash, a full set of *GNU CoreUtils* are
|
223
|
+
available as well (accessible out of the *Docker Quickstart Terminal*). The
|
224
|
+
used (bash) test script needs to be run out of *Docker Quickstart Terminal*.
|
225
|
+
Download the tester script from here.
|
226
|
+
|
227
|
+
The test script *docker_perf_test.sh* supports a test scenario for
|
228
|
+
*General System Performance*. This is focussing on pure CPU|Memory power.
|
229
|
+
On both systems (host and guest) these tests are using pure *kernel services*
|
230
|
+
for creating input and output data. One is creating random input data as
|
231
|
+
fast as possible, the other discards everything it gets as fast as it can.
|
232
|
+
|
233
|
+
.General System Performance
|
234
|
+
[source, sh]
|
235
|
+
----
|
236
|
+
dd if=/dev/urandom of=/dev/null bs=1M count=10000
|
237
|
+
----
|
238
|
+
|
239
|
+
Please see those tests for *General System Performance* for the background
|
240
|
+
*What could be achived in therory*. These tests may helpful to compare your
|
241
|
+
current setup for the host and the guest same way.
|
242
|
+
|
243
|
+
As mentioned, all tests for *docker_perf_test.sh* are based on the `dd`
|
244
|
+
command. For *real world* measures, standard *dd tests* are used. You'll
|
245
|
+
find a lot of those on the Internet. All tests for *docker_perf_test.sh* are
|
246
|
+
changed (from `/dev/zero`) to `/dev/urandom` for the input to put some
|
247
|
+
*pressure* on the CPU while processing data for reading or writing from the
|
248
|
+
filesystem to be checked. All the tests are *rules of thumb*, no technical
|
249
|
+
measures.
|
250
|
+
|
251
|
+
NOTE: Zum Messen der Schreibperformance liest man die zu Schreibenden
|
252
|
+
Daten am besten aus /dev/zero und schreibt eine normale Datei im Filesystem
|
253
|
+
(z.B. mit of=/root/testfile). Die folgenden Beispiele verwenden ein Testdatei,
|
254
|
+
um irrtümlichen Datenverlust zu vermeiden. Die dabei erzielbare Performance
|
255
|
+
Werte sind etwas geringer (da dadurch auch Metadaten im Filesystem geschrieben
|
256
|
+
werden).
|
257
|
+
|
258
|
+
Find the base `dd` commands for read an write performance tests below. The
|
259
|
+
exported shared folder on Windows is *C:\Users\Public* mapped to the Unix
|
260
|
+
(POSIX) folder scheme of */c/Users/Public* on the guest OS.
|
261
|
+
|
262
|
+
.Write Performance - Windows host (local disk), Linux guest (shared disk)
|
263
|
+
[source, sh]
|
264
|
+
----
|
265
|
+
dd if=/dev/urandom bs=1M count=1024 | split -b 1M - name.
|
266
|
+
----
|
267
|
+
.Write Performance (local disk), Linux guest
|
268
|
+
[source, sh]
|
269
|
+
----
|
270
|
+
dd if=/dev/urandom of=/var/tmp/test/samplefile bs=1M count=1024
|
271
|
+
----
|
272
|
+
|
273
|
+
.Read Performance - Windows host (local disk), Linux guest (shared disk)
|
274
|
+
[source, sh]
|
275
|
+
----
|
276
|
+
dd if=/c/Users/Public/test/samplefile of=/dev/null bs=1M count=1024 iflag=direct
|
277
|
+
----
|
278
|
+
.Read Performance (local disk), Linux guest
|
279
|
+
[source, sh]
|
280
|
+
----
|
281
|
+
dd if=/var/tmp/test/samplefile of=/dev/null bs=1M count=1024 iflag=direct
|
282
|
+
----
|
283
|
+
|
284
|
+
Have a look at the table below for the measures found on a *Windows 10*
|
285
|
+
desktop host (Intel Core Quad Q9550) using a *SATA-300* disk for the local
|
286
|
+
physical disk and a Gigabit network interface (*Realtek PCIe GBE* familiy)
|
287
|
+
running a *CentOS 7 Linux* (version 3.10.0-862) as a guest:
|
288
|
+
|
289
|
+
.Data transfer rates for 1 GB of data
|
290
|
+
[cols="2,2,4,3, options="header", role="table-responsive, full-width"]
|
291
|
+
|===============================================================================
|
292
|
+
|direction |mountpoint |source |througput [MB/s]
|
293
|
+
|
294
|
+
|`read`
|
295
|
+
|/mnt/media/repo1
|
296
|
+
|physical (local) disk on the *host*
|
297
|
+
|85.20
|
298
|
+
|
299
|
+
|`read`
|
300
|
+
|/mnt/media/repo2
|
301
|
+
|physical (local) disk on the *guest*
|
302
|
+
|147.00
|
303
|
+
|
304
|
+
|`read`
|
305
|
+
|/mnt/media/repo3
|
306
|
+
|shared disk on the *guest*
|
307
|
+
|30.3
|
308
|
+
|
309
|
+
|`write`
|
310
|
+
|/mnt/media/repo1
|
311
|
+
|physical (local) disk on the *host*
|
312
|
+
|234.00
|
313
|
+
|
314
|
+
|`write`
|
315
|
+
|/mnt/media/repo2
|
316
|
+
|physical (local) disk on the *guest*
|
317
|
+
|34.00
|
318
|
+
|
319
|
+
|`write`
|
320
|
+
|/mnt/media/repo3
|
321
|
+
|shared disk on the *guest*
|
322
|
+
|39.9
|
323
|
+
|
324
|
+
|===============================================================================
|
325
|
+
|
326
|
+
WARNING: Bei Verwendung von if=/dev/zero und bs=1G benötigt das Linuxsystem
|
327
|
+
1GB freien Platz im RAM. Falls Ihr Testsystem nicht ausreichend RAM ...
|
328
|
+
|
329
|
+
NOTE: Um praxisnahe Ergebnisse zu erhalten empfehlen wir die beschrieben Tests
|
330
|
+
mehrmals (z.B. 3 bis 10x) durchzuführen. Damit können Sie Ausreißer rechtzeitig
|
331
|
+
erkennen.
|
332
|
+
|
333
|
+
|
334
|
+
lorem:sentences[5]
|
335
|
+
|
336
|
+
== Publish a Shared Folder
|
337
|
+
|
338
|
+
lorem:sentences[5]
|
339
|
+
|
340
|
+
lorem:sentences[3]
|
341
|
+
|
342
|
+
|
343
|
+
== Mount Shared Folders on Linux
|
344
|
+
|
345
|
+
lorem:sentences[5]
|
346
|
+
|
347
|
+
=== Installing CIFS
|
348
|
+
|
349
|
+
For the Linux VM, a current Ubunt Server of version 18.06 is used. To mount
|
350
|
+
CIFS shares, the package `cifs-utils` needs to be installed:
|
351
|
+
|
352
|
+
[source, bash]
|
353
|
+
----
|
354
|
+
sudo apt-get -y install cifs-utils
|
355
|
+
----
|
356
|
+
|
357
|
+
Mounting filesystems in general, therefor the same to the CIFS share, are
|
358
|
+
done as root. This ends up in the situation this folder cannot (accessed??)
|
359
|
+
written as normal user.
|
360
|
+
|
361
|
+
. Create the `cifs` group
|
362
|
+
+
|
363
|
+
[source, bash]
|
364
|
+
----
|
365
|
+
sudo groupadd cifs
|
366
|
+
----
|
367
|
+
|
368
|
+
[start=2]
|
369
|
+
. Add your user to the `cifs` group
|
370
|
+
+
|
371
|
+
[source, bash]
|
372
|
+
----
|
373
|
+
sudo usermod -aG cifs $USER
|
374
|
+
----
|
375
|
+
|
376
|
+
[start=3]
|
377
|
+
. Create the mountpoint (to be used by Docker) as root
|
378
|
+
+
|
379
|
+
[source, bash]
|
380
|
+
----
|
381
|
+
mkdir -p /c/Users/Public
|
382
|
+
----
|
383
|
+
|
384
|
+
[start=4]
|
385
|
+
. Change the ownership of the mountpoint
|
386
|
+
+
|
387
|
+
[source, bash]
|
388
|
+
----
|
389
|
+
chown -R root:cifs /c/Users/Public
|
390
|
+
----
|
391
|
+
|
392
|
+
[start=5]
|
393
|
+
. Create a credentials file to place user|password data safe.
|
394
|
+
+
|
395
|
+
[source, bash]
|
396
|
+
----
|
397
|
+
touch ~/.smbcredentials
|
398
|
+
----
|
399
|
+
|
400
|
+
.smbcredentials
|
401
|
+
----
|
402
|
+
username=<your_windows_user>
|
403
|
+
password=<windows_user_password>
|
404
|
+
----
|
405
|
+
|
406
|
+
=== Mount the share manually
|
407
|
+
|
408
|
+
To enable non-authorized users to read and write the shared files, specify
|
409
|
+
user and group ID that the mounted shares folders should use. This would
|
410
|
+
allow particular users and group members to read|write to the share.
|
411
|
+
|
412
|
+
To do so, the following options are used for a public mount:
|
413
|
+
|
414
|
+
* username
|
415
|
+
* password
|
416
|
+
* uid
|
417
|
+
* gid
|
418
|
+
|
419
|
+
Add the Windows host IP address to the hosts file
|
420
|
+
|
421
|
+
./etc/hosts
|
422
|
+
<ip_v4_address> <name_of_the windows_box> <alias_name>
|
423
|
+
|
424
|
+
|
425
|
+
=== Mount the share at boot-time
|
426
|
+
|
427
|
+
lorem:sentences[3]
|
428
|
+
|
429
|
+
./etc/fstab
|
430
|
+
//win10pc/Public /c/Users/Public cifs uid=1000,gid=5555,credentials=/home/jadams/.smbcredentials,iocharset=utf8,rw 0 0
|