Page 6 of 12

Re: Suggestions

Posted: 12 Nov 2015, 23:32
by brokenman
Is now a PASS while it was a FAIL with your current ISO certificates.
Did you run: update-ca-trust to update the certificates before running your test?

Re: Suggestions

Posted: 12 Nov 2015, 23:40
by aus9
Did you run: update-ca-trust to update the certificates before running your test?
No will try again later as I have booted into changes with a live injection of my stuff which I will need to remove from changes.

EDIT rebooted now with update-ca-trust

Code: Select all

ls -al /etc/ssl/certs  (snip)
drwxr-xr-x 2 root root  4096 Nov 13 07:56 java
lrwxrwxrwx 1 root root    64 Nov 13 07:56 thawte_Primary_Root_CA.pem -> ../../ca-certificates/extracted/cadir/thawte_Primary_Root_CA.pem
snip

ls -al /etc/ssl | grep pem
lrwxrwxrwx  1 root root    46 Apr  3  2015 cert.pem -> ../ca-certificates/extracted/tls-ca-bundle.pem
Now to try my test again

Code: Select all

git clone https://code.google.com/p/setuid-sandbox/
Cloning into 'setuid-sandbox'...
fatal: unable to access 'https://code.google.com/p/setuid-sandbox/': error setting certificate verify locations:
  CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
Having opened my big gob and put my foot in it with some effort, I observe that to my my eyesight etc this test is a FAIL but your settings appear to allow it to be a PASS?

And that of course can be excused by my lack of knowledge of Porteus/Nemesis but feel free to share what else I need to do please.

ahh found one issue there is no such file

Code: Select all

ls /etc/ssl/certs/ca*  -> returns no target ca-certificates.crt

Code: Select all

ln -s /etc/ssl/cert.pem /etc/ssl/certs/ca-certificates.crt
root /tmp # git clone https://code.google.com/p/setuid-sandbox/
Cloning into 'setuid-sandbox'...
Unpacking objects: 100% (89/89), done.
Checking connectivity... done.
Maybe on rebuild you can do the update and make that sym link?

Re: Suggestions

Posted: 13 Nov 2015, 01:02
by brokenman
/etc/ssl/cert.pem -> ../ca-certificates/extracted/tls-ca-bundle.pem

This file is created after running the update. I will include the files in the next release. Thanks for sniffing it out.

Re: Suggestions

Posted: 13 Nov 2015, 01:26
by brokenman
This may be an upstream bug as the ca-certificates packages should contain the /etc/ssl/certs/ca-certificates.crt.
This is also breaking other packages like pacaur and curl over https. Thanks again.

Re: Suggestions

Posted: 13 Nov 2015, 05:37
by aus9
Thanks for checking that out. I now feel no pressure to honour my earlier request to build a certs XZM at this stage.
I have yet to find how the mtree is created, looks like I can read this at my later
https://gist.github.com/Earnestly/bebad057f40a662b5cc3

Re: Suggestions

Posted: 13 Nov 2015, 06:00
by francois
We will have to find a way to simplify installation upgrades which will have some AUR packages on them. It seems that these AUR packages have to be reinstalled. Maybe keeping a copy of the package before installation could do the trick.

Not sure. :(

Re: Suggestions

Posted: 13 Nov 2015, 06:38
by aus9
@brokenman

At the risk of flogging a dead horse, as its not yet the weekend can I give you some pointers based on files you can compare in Porteus that might help you?
I currently have installed on Porteus ca-certificates-20150426-noarch-2_slack14.1.xzm

Code: Select all

ls -al /usr/share/ca-certificates/mozilla/
Should return real files, not sym links of the kind Common_Name.crt

Code: Select all

ls -al /etc/ssl/certs
Shoud show sym links from Common_Name.pem to /usr/share/ca-certificates/mozilla/Common_Name.crt or some other root authority

The c_rehash command then creates new sym links in /etc/ssl/certs so
string.crt sym links to Common_Name.pem within the same dir.

This has to be done before you add the bundle to the /etc/ssl/certs. ....ca-certificates.crt must be found in /etc/ssl/certs as you already know a lot of software/domains look here first. If you try to do it early, which I have done, :oops: you will get a false output because c_rehash only reads the top hash value in each pem file and you have 2, the top part of ca-certificates.crt and one called something_Common_Name.pem

The sym link to its bundle-name.pem can be anywhere.

Forgive me for sucking eggs, I have actually built this package on another distro but am no longer a member of that distro. And that is why my build script a few posts above is written in that way. Naturally I will volunteer to test this on next rebuild whether they are modules or the fulll iso

good luck

Re: Suggestions

Posted: 14 Nov 2015, 15:26
by fullmoonremix

Re: Suggestions

Posted: 14 Nov 2015, 23:41
by aus9
@brokenman
for some later rebuild, include the man pages for pacman.

Code: Select all

pacman -h 
works for me but is so short on details and examples I think I can handle a little extra bloat.

Looks in mirror....err maybe not. :D

found the webpage
https://www.archlinux.org/pacman/pacman.8.html

Re: Suggestions

Posted: 16 Nov 2015, 20:38
by fullmoonremix
Salutations... :good:

Instead of aufs? AlienBob has chosen this for his Slackware Live.
OverlayFS

Best Regards... :beer:

Re: Suggestions

Posted: 17 Nov 2015, 01:00
by brokenman
Yes I was looking at porting all the aufs stuff to overlayfs because this is the way things will probably go, but overlayfs is still relatively new and we have no big bugs with aufs which is still being actively developed. Junjiro does a fantastic job so I would like to support him.

Re: Suggestions

Posted: 18 Nov 2015, 23:40
by brokenman
Thanks. Some interesting ideas.

001-porteus-pack(kit, soft?).xzm it's Porteus-scripts-file-configuration-patches-graphics-etc - it's all what makes Porteus himself.
The problem here is that many of these files are not required in a text mode Portues. The ones that are required only for GUI go in 002.

for example to add the ability to specify in porteus.cfg the download directory (root=/porteus-new or root=label='name') +to facilitate pre-configuration via file porteus.ini
The config folder has the functionality to configure options.

Let's go to the Manjaro repositories as a more stable and extensive.
A few people have suggested this. Is there a difference between this and just using a set date int he arch repositories?

Adapt installer from manjaro-net edition(it's very good) for preconfiguration of Porteus.
I will check out the installer. Thanks.

Go to common for rolling-release numbering (year.month-rc3) Add the ability to boot from a different kernels(a standard feature of Manjaro)
I plan to use a 'kernel update' feature but only boot from one kernel. Most people have no need to choose a kernel to boot from.

Be prepared to sacrifice size in favor of functionality, stability, and time for personal life.
This is a good point, however we enter a different niche if we exit the 'lightweight' distro category. 300MB is my proposed maximum.

Re: Suggestions

Posted: 19 Nov 2015, 00:41
by brokenman
@Francois I rememeber you suggested using networkmanager for setting up network instead of netctl. In retrospect this was a wise piece of advice. Due to the conflict of netctl and the NetworkManager service I will be employing your idea. Thanks.

Re: Suggestions

Posted: 21 Nov 2015, 17:45
by francois
@brokenman:
Thanks for networkmanager and nm-applet.

I am providing for the vbox guest addition on the download page of nemesis.

Is is possible to have mloop on nemesis or archporteus? Untar ... would also be appreciated.

Thanks.

Re: Suggestions

Posted: 25 Nov 2015, 07:27
by aus9
In case its not in your TODO list

can git be added to the 05-devel.xzm please