On 12/29/2017 12:48 PM, J D wrote:
> Thanks you two, but i dont have /etc/kernel/ or /boot/loader :x
>
> I do and other manual install for parameters.
you can just create the /etc directories
/boot isn't mounted by default but a
mount /dev/sda1 /boot
should mount it
On 12/29/2017 7:07 AM, J D wrote:
> Hello,
>
> I have CLR bare metal & clr-boot-manager.
>
> What i can do to add "vsyscall=emulate" in kernel option all the time ?
> I dont find where is grub :s
you can stick a file in a /etc/kernel/cmdline.d directory and it will be used for newly installed kernels
for already installed kernels, look in the /boot/loader/entries/Clear-linux-native-4.14.6-375.conf
(kernel version may vary ;-)
Hello,
I have CLR bare metal & clr-boot-manager.
What i can do to add "vsyscall=emulate" in kernel option all the time ?
I dont find where is grub :s
Thx guy.
On 12/28/2017 2:24 PM, Jorge Castro wrote:
> you have that, you might as well include flathub.org for
> gnome-software/flatpak as well and then that probably is a rabbit hole
> towards a generic distribution so I'm not sure if that level of integration
> is a goal for clearlinux.
I for sure would like the experience to be great for the power user side of the user spectrum...
... and we'll invest work in getting there.. so by all means, please bring these things up.
>
> So are people generally happy with the vanilla gnome experience or is
> anyone else also building and playing around with extensions? The idea
> being is if I can just get a few UI niggles out of the way with extensions
> then I can just use the same distro across everything and not have version
> drift. Thanks for your time!
>
>
> [1]: https://addons.mozilla.org/en-US/firefox/addon/gnome-shell-integration/
> [2]: https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome
> /Installation
> _______________________________________________
> Dev mailing list
> Dev(a)lists.clearlinux.org
> https://lists.clearlinux.org/mailman/listinfo/dev
>
Hi everyone,
I initially discovered clearlinux as a good way to try clear containers
with kubernetes, etc. and it's been great for that. As it turns the combo
of cloud bundles makes it an ideal desktop for me. I usually need the
latest version of cloud native tools and having a matching set on my laptop
as well as my servers is nice. I am not sure if I'm an edge case yet or
not. :D
I've been exploring a few ways to use GNOME extensions on my client
machines for quality-of-life and thought I'd share some thoughts.
<https://extensions.gnome.org/>
<https://extensions.gnome.org/>
https://extensions.gnome.org/ has the index of extensions. Installation of
the extension[1] for Firefox works, but there's a connector[2], which
builds fine but I can't seem to get it to work.
Another method is just building an extension locally. This tends to be hit
or miss, some of them are well documented and build easily, while some are
just dumped onto github.
In the latest Fedora Atomic I noticed that they had the GNOME extensions
just listed in a section of gnome-software, which means I didn't need to
bother with a browser extension or connector shim. Then I was thinking, if
you have that, you might as well include flathub.org for
gnome-software/flatpak as well and then that probably is a rabbit hole
towards a generic distribution so I'm not sure if that level of integration
is a goal for clearlinux.
So are people generally happy with the vanilla gnome experience or is
anyone else also building and playing around with extensions? The idea
being is if I can just get a few UI niggles out of the way with extensions
then I can just use the same distro across everything and not have version
drift. Thanks for your time!
[1]: https://addons.mozilla.org/en-US/firefox/addon/gnome-shell-integration/
[2]: https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome
/Installation
On 12/20/2017 01:02 PM, Arzhan Kinzhalin wrote:
> Thank you, Auke! I will add this to https://github.com/clearlinux/clrtrust .
>
> I was about to release a new version, so this comes in a convenient time.
> Thanks! My only concern is that it duplicates a lot of what is in README.md. So
> I think this needs to be a PR to https://github.com/clearlinux/clrtrust and
> clrtrust.1.md and README.md should be merged into one and fed to ronn.
>
Yes, we certainly can.
I would propose to keep the readme, but make it a document that covers
angles that the manual page doesn't cover:
- license statement
- some documentation on the internals on how it works (man pages are
generally opaque - they describe what it does, but generally not how)
- some simple use cases and things you can do with it
Then the readme can become the start of a webpage on the clearlinux.org
website, as well, and these documents work together better and can refer
to eachother.
Auke
This basic .md formatted text serves as a starter UNIX man
page that covers the basics of `clrtrust` and covers the currently
implemented functionality. It borrows from the README.md where
appropriate.
The Makefile includes a necessary rule to create the roff formatted
output. Since we don't want to run `ronn` during packaging, we
ship the compiled output file as well. Developers modifying the
man page need to regenrate the output file by running `make`.
---
Makefile | 6 ++-
clrtrust.1 | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
clrtrust.1.md | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 236 insertions(+), 1 deletion(-)
create mode 100644 clrtrust.1
create mode 100644 clrtrust.1.md
diff --git a/Makefile b/Makefile
index b976ebd..70b9e45 100644
--- a/Makefile
+++ b/Makefile
@@ -1,9 +1,13 @@
# Copyright 2017 Intel Corporation.
-all:
+all: clrtrust.1
@true
+clrtrust.1: clrtrust.1.md
+ ronn -r --pipe < clrtrust.1.md > clrtrust.1
+
install:
install -D --mode=0755 clrtrust ${INSTALL_ROOT}/usr/bin/clrtrust
+ install -D --mode=0644 clrtrust.1 ${INSTALL_ROOT}/usr/share/man/man1/clrtrust.1
check:
bats -t test
diff --git a/clrtrust.1 b/clrtrust.1
new file mode 100644
index 0000000..dec6707
--- /dev/null
+++ b/clrtrust.1
@@ -0,0 +1,115 @@
+.\" generated with Ronn/v0.7.3
+.\" http://github.com/rtomayko/ronn/tree/0.7.3
+.
+.TH "CLRTRUST" "1" "December 2017" "" ""
+.
+.SH "NAME"
+\fBclrtrust\fR \- The Clear Trust Store Management tool
+.
+.SH "SYNOPSIS"
+\fB/usr/bin/clrtrust\fR
+.
+.P
+\fBclrtrust\fR [OPTIONS\.\.\.] [COMMAND] [PARAMETERS\.\.\.]
+.
+.P
+\fB/var/cache/ca\-certs\fR
+.
+.SH "DESCRIPTION"
+Clear Linux* for Intel® Architecture implements a centralized TLS Trust Store for all its packages which use Transport Layer Security\. The trust store contains a set of trusted Root Certificate Authorities (CAs) which Clear Linux* should trust\. \fBclrtrust\fR tool provides a front\-end for the trust store management: it allows viewing, adding (trusting), removing (distrusting) CAs\. It also provides some maitenance commands such as re\-generating the trust store and checking its consistency\.
+.
+.SH "OPTIONS"
+The following options are understood:
+.
+.TP
+\fB\-\-help\fR, \fB\-h\fR:
+.
+.IP
+Prints a help message\.
+.
+.TP
+\fB\-\-verbose\fR, \fB\-v\fR:
+.
+.IP
+Verbose output of actions performed\.
+.
+.TP
+\fB\-\-force\fR, \fB\-f\fR:
+.
+.IP
+Overrides basic sanity checks and forces the command to complete even if these checks fail\.
+.
+.SH "COMMANDS"
+.
+.TP
+\fBadd\fR [FILENAME]:
+.
+.IP
+Add trust to the trust store for the provided Root CA\. The file must be a certificate file in the PEM\-encoded format, and have one certificate only\.
+.
+.IP
+If the filename is in a different format, you should convert the certificate into the PEM format with e\.g\. the openssl tool:
+.
+.IP
+\fBopenssl x509 \-in file\.cer \-inform der \-out file\.pem \-outform pem\fR
+.
+.TP
+\fBremove\fR [FILENAME|ID]:
+.
+.IP
+Removes trust for the provided Root CA\. The Root CA may be provided as the file (PEM\-encoded) as it was provided when it was added to the trust store, or it can be provided by the ID of the Root CA\. Use the \fBlist\fR command to find the ID of the Root CA\.
+.
+.TP
+\fBgenerate\fR:
+.
+.IP
+Regenerates the trust store\. Normally, this is not needed to be executed by users directly, as the distribution and the \fBadd\fR and \fBremove\fR commands already indirectly perform this action\. Use this command to ensure that the trust store is in a consistent state\.
+.
+.TP
+\fBlist\fR:
+.
+.IP
+Lists the contents of the trust store\. The command will output a brief summary of each certificate contained in the store, which looks as follows:
+.
+.IP
+\fBid: <fingerprint>\fR \fBFile: <path>\fR \fBAuthority: <authority section>\fR \fBExpires: <expiry date>\fR
+.
+.IP
+The \fBid\fR fingerprint uniquely identifies the certificate\. It can be passed to \fBclrtrust remove\fR as an argument to remove trust for a certificate\.
+.
+.IP
+The \fBFile\fR provides the exact file on disk where the certificate is stored as part of the trust store\. This is provided so that one may inspect the certificate in more detail with tools like \fBopenssl\fR:
+.
+.IP
+\fBopenssl x509 <path> \-noout \-text\fR
+.
+.IP
+The Authority field describes the Issuing party of the certificate, and contains the Name and Organization of the issuer\.
+.
+.IP
+The Expires field contains the date when the certificate expires\. After this date, the certificate will no longer be valid and will not be used to grant trust\.
+.
+.SH "EXIT STATUS"
+On success, 0 is returned, a non\-zero failure code otherwise\.
+.
+.SH "COPYRIGHT"
+.
+.IP "\(bu" 4
+Copyright (C) 2017 Intel Corporation, License: CC\-BY\-SA\-3\.0
+.
+.IP "" 0
+.
+.SH "SEE ALSO"
+\fBopenssl\fR(1)
+.
+.SH "BUGS"
+Report bugs to: \fBdev(a)lists\.clearlinux\.org\fR or visit \fBhttps://github\.com/clearlinux/clrtrust/issues\fR
+.
+.SH "NOTES"
+Creative Commons Attribution\-ShareAlike 3\.0 Unported
+.
+.IP "\(bu" 4
+http://creativecommons\.org/licenses/by\-sa/3\.0/
+.
+.IP "" 0
+
diff --git a/clrtrust.1.md b/clrtrust.1.md
new file mode 100644
index 0000000..364ff6d
--- /dev/null
+++ b/clrtrust.1.md
@@ -0,0 +1,116 @@
+clrtrust(1) -- The Clear Trust Store Management tool
+====================================================
+
+## SYNOPSIS
+
+`/usr/bin/clrtrust`
+
+`clrtrust` [OPTIONS...] [COMMAND] [PARAMETERS...]
+
+`/var/cache/ca-certs`
+
+## DESCRIPTION
+
+Clear Linux\* for Intel® Architecture implements a centralized
+TLS Trust Store for all its packages which use Transport Layer
+Security. The trust store contains a set of trusted Root Certificate
+Authorities (CAs) which Clear Linux\* should trust. `clrtrust` tool
+provides a front-end for the trust store management: it allows viewing,
+adding (trusting), removing (distrusting) CAs. It also provides some
+maitenance commands such as re-generating the trust store and checking
+its consistency.
+
+## OPTIONS
+
+The following options are understood:
+
+ * `--help`, `-h`:
+
+ Prints a help message.
+
+ * `--verbose`, `-v`:
+
+ Verbose output of actions performed.
+
+ * `--force`, `-f`:
+
+ Overrides basic sanity checks and forces the command to complete
+ even if these checks fail.
+
+## COMMANDS
+
+ * `add` [FILENAME]:
+
+ Add trust to the trust store for the provided Root CA. The file
+ must be a certificate file in the PEM-encoded format, and have one
+ certificate only.
+
+ If the filename is in a different format, you should convert the
+ certificate into the PEM format with e.g. the openssl tool:
+
+ `openssl x509 -in file.cer -inform der -out file.pem -outform pem`
+
+ * `remove` [FILENAME|ID]:
+
+ Removes trust for the provided Root CA. The Root CA may be provided as
+ the file (PEM-encoded) as it was provided when it was added to the trust
+ store, or it can be provided by the ID of the Root CA. Use the `list`
+ command to find the ID of the Root CA.
+
+ * `generate`:
+
+ Regenerates the trust store. Normally, this is not needed to be
+ executed by users directly, as the distribution and the `add` and
+ `remove` commands already indirectly perform this action. Use this
+ command to ensure that the trust store is in a consistent state.
+
+ * `list`:
+
+ Lists the contents of the trust store. The command will output a
+ brief summary of each certificate contained in the store, which
+ looks as follows:
+
+ `id: <fingerprint>`
+ ` File: <path>`
+ ` Authority: <authority section>`
+ ` Expires: <expiry date>`
+
+ The `id` fingerprint uniquely identifies the certificate. It can
+ be passed to `clrtrust remove` as an argument to remove trust for
+ a certificate.
+
+ The `File` provides the exact file on disk where the certificate
+ is stored as part of the trust store. This is provided so that one
+ may inspect the certificate in more detail with tools like `openssl`:
+
+ `openssl x509 <path> -noout -text`
+
+ The Authority field describes the Issuing party of the certificate,
+ and contains the Name and Organization of the issuer.
+
+ The Expires field contains the date when the certificate expires.
+ After this date, the certificate will no longer be valid and will
+ not be used to grant trust.
+
+## EXIT STATUS
+
+On success, 0 is returned, a non-zero failure code otherwise.
+
+## COPYRIGHT
+
+ * Copyright (C) 2017 Intel Corporation, License: CC-BY-SA-3.0
+
+## SEE ALSO
+
+`openssl`(1)
+
+## BUGS
+
+Report bugs to: `dev(a)lists.clearlinux.org` or visit
+`https://github.com/clearlinux/clrtrust/issues`
+
+## NOTES
+
+Creative Commons Attribution-ShareAlike 3.0 Unported
+
+ * http://creativecommons.org/licenses/by-sa/3.0/
--
2.15.1
Hi Everyone,
The redesigned clearlinux.org<http://clearlinux.org/> website is live! This new website boasts the following improvements:
* Consolidates Clear Linux website content and the documentation coming from GitHub to double search engine ranking and improve the in-site searching experience
* Removes the last of any outdated/inaccurate Clear Containers and Ciao content
* Boasts a new “community” section to direct eager contributors or folks with questions
* Simplifies the Clear Linux content submission process for all contributors, widening the pipeline for fresh content.
* Implements Drupal 8 web components, enabling layout changes without web development expertise so we can completely redesign in minutes if we so choose.
* Provides a way to highlight content without duplicating it.
Please join me in thanking some of the folks responsible for these great changes:
Sphinx to Drupal and documentation consolidation approach – Rodrigo Caballero and Daniel Serna
Web architecture, Backend development, release management, infra first response – Daniel Serna
UX, imagery, and mockups – Jimena Flores
Frontend development - Noelia Nunez
Frontend style guides – Julio Rivera
Editors tutorial and content migration – Daniel Chacon
QA – Tom Leavitt
Server setup, install and config services, pre-prod testing & the move to production – Dave Hewitt
We greatly appreciate your work!
Please don’t hesitate to contact me with any questions or comments regarding the redesign. I have been noting minor bugs to be fixed in our first iteration coming very soon :)
Thanks!
Ianeta
