Freeduc-jbart' security ... see below
The gross method is to burn 16 GB into the USB stick. Downloading the data is of course the same, with Windows or with GNU/Linux. The gross method cannot fit USB stick with sizes bigger or smaller then 16GB.
Date | Image for 16 Gb USB stick | Checksum | Signature |
---|---|---|---|
target = x64 (64 bits) |
5190897345 |
||
target = x64 (64 bits) |
3398331 |
||
target = i686 (32 bits) |
3301939 |
||
target = x64 (64 bits) |
3123743 |
||
target = x64 (64 bits) |
3052155 |
||
First version generated by live-build, target = x64 (64 bits) |
3348038 |
Anyone can use this method since year 2019, when Freeduc flash sticks first were forged with live-build. One just needs to download and copy partitions containing the system's core; they are five times smaller to copy bitwise to the USB stick: one burns 3 GB instead of burning 16 GB.
One downloads the system's image in ISO-hybrid format. No need to uncompress it.
Date | ISO file | Checksum | Signature | Sources tarball |
---|---|---|---|---|
target = x64 (64 bits) |
4635574272 |
14035507200 |
||
target = x64 (64 bits) |
3319456 |
9888690 |
||
target = i686 (32 bits) |
3299872 |
9840380 |
||
target = x64 (64 bits) |
3123232 |
9313660 |
||
target = x64 (64 bits) |
3025120 |
8521660 |
||
First version generated by live-build, target = x64 (64 bits) |
3031040 |
Then you must copy the image bitwise, not as a plain file, to the USB stick. This works correctly only when the size of the USB stick is 16 GB. For a 8 GB stick, the persistence filesystem will be inconsistent, one would have to fix it, and for bigger USB sticks, there would be unused memory space.
Beware : with Windows, people are used to ordinary « copy systems » for USB sticks, like dragging, copying, pasting, etc. with the mouse; this cannot work. Using a special program to perform bitwise copying is mandatory. One can use Win32 Disk Imager . One launch Win32 Disk Imager, choose the target USB stick, choose the 16 GB uncompressed file, and trigger the copy process. Depending on the stick's quality, the copy's duration is between 10 minutes and some hours. If the duration exceeds half an hour, a better stick quality should be chosen.
Then you must copy the image bitwise, not as a plain file, to the USB stick. This works correctly only when the size of the USB stick is 16 GB. For a 8 GB stick, the persistence filesystem will be inconsistent, one would have to fix it, and for bigger USB sticks, there would be unused memory space.
Then you must copy the image bitwise, not as a plain file, to the USB stick. This works correctly only when the size of the USB stick is 16 GB. For a 8 GB stick, the persistence filesystem will be inconsistent, one would have to fix it, and for bigger USB sticks, there would be unused memory space.
In command-line mode, still with super-user permissions, one has to use a partition management tool to create the persistence partition, to use the space which remains at the end of the device.
Keeping on with the example, the stick is still managed by /dev/sdb, type the command fdisk /dev/sdb; that stats the interactive program fdisk. When it is running, one can see the internals of the systems born by the USB stick: type p (Print) : fdisk will show the existing partitions, numbered 1 and 2.
While fdisk is in use, type n (New), and p (Primary partition), and 3, finally validate a few times with the Enterkey. This creates a third partition using all of the remaining space. Type p (Print), the new structure can be checked: three partitions, numbered 1, 2 and 3. If everything is correct, type w (Write): this overwrites the previous version of the partition table. One can cancel the operations if any doubt, by typing q (Quit); it stops fdisk without modifying the partition table.
A configuration file must be put in the recently created partition. One can use a graphic tool to manage files; it should detect a partition named persistence, if there is none, one could try to unplug the stick and plug it again a few seconds later. The file manager allows one to see the partition, but if it is not launched with root permission, it is unable to touch directly files in that partition. However, it can tell the precise directory where the partition is mounted. Typically, something like /media/foo/persistence (foo is not the real name, it is more probably the user name instead).
Create a plain text file somewhere, with the file name persistence.conf, with a single line in it : / union; carefully check the file name, and the space between the character / and the word union. Finally, as a super-user, copy the file to the right place: cp persistence.conf /media/foo/persistence (of course, the user is not named foo, use the real name).
Actually, the complete "fine method" with GNU/Linux has been scripted into a program quite easy to use, named live-clone. Download the most recent Debian package and install it:
Publication date | File | Size |
---|---|---|
November 2022 | live-clone version 2.6-1 | 545 KB |
November 2020 | live-clone_2.4-1_all.deb | 533 KB |
The package manager may ask to install a few other packages automatically: they are dependencies of package live-clone. Let it do the work, so the install can go to its end seamlessly.
When the install is finished, one should be able to see the
application in administration menus, with its icon:
Live-Clone
One can launch the application from the menus, or from a
terminal (sudo live-clone). In either case, one needs
to get administration permissions, so one must type a password.
Then it is quite too easy! When a USB stick
is plugged in, it appears immediately in a table, and a click
on the big title
CLONING LIVE STICKS allows one
to trigger the action.
On just needs to choose the file
live-image-amd64.hybrid.iso in the appropriate dialog,
and let the application do the remaining.
Once one has installed his first Freeduc-Jbart USB stick from June 2019 or later, it comes with the program live-clone already installed. In the context of the live USB stick, the clone button asks nothing (no file dialog): it just clones the flash stick itself.
live-clone does not copy data from the persistence partition, in order to avoid personal data leaks: those must remain under one's responsibility.
The one who starts a computer with the USB stick Freeduc-Jbart can obtain all rights on the the local machine. It is precisely one goal of this distribution: provide teachers and students with an acute tool, to control a computer.
In an educational context, the teacher tells his students what they may do and what they may not. The access to "acute tools" requires gaining super-user permissions, for example with the command sudo. If the training is well done, students are respectful towards their teacher and also to computers they access to.
However, what would happen if the USB stick comes with malignant programs, for example with a virus with an unwanted payload?
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
However, I, publisher of this distribution, affirm that as long as I know, no malignant software was introduced, and that all software packages inside obey the rules of the Debian Social Contract .
Georges Khaznadar
As anybody knows, it is most easy to publish a web page, pretending to provide good software: the best viruses come exactly in such pages.
The files which you download can be verified by a strong cryptographic method, and you can establish with a pretty good reliability that they were signed by Georges Khaznadar <georgesk@debian.org>, with the GPG key whose id is 3340B364FF67153FB7CCAE851C2816907136AE39. This key belongs to the Web of Trust , and you can subscribe to the Web of Trust to get a reliable confirmation.
In addition to files of the distribution, there are files with MD5 checksums, and files with a digital signature of the checksums files.
For example, for the file live-image-i386.hybrid.iso , the checksum is in the file sha512sums.txt , and the digital signature of the latter file is in the file sha512sums.txt.asc
Let us suppose that those three files, .iso, .txt, and
.txt.asc are downloaded into the same directory.
Then, the command sha512sum -c sha512sums.txt
allows you to check that the big file with 3 GB was not altered.
Finally, the command gpg --verify sha512sums.txt.asc allows you to verify that the checksum file has not been altered, and that it is digitally signed by Georges Khaznadar <georgesk@debian.org>, with the GPG key id 3340B364FF67153FB7CCAE851C2816907136AE39.
If you enter the Web Of Trust, you can evidence clearly all the trust paths between yourself and the author of the signature, for example with the web page pgp.cs.uu.nl .