Re: [Tails-dev] Modifying Tails-greeter to work outside of Tails

2016-11-15 Thread adrian15

El 07/10/16 a las 20:43, intrigeri escribió:

Hi adrian15!

adrian15:

   So, what I have been trying to do is to tweak minimally tails-greeter so 
that it
meets my needs. The final purpose of these tweaks is to convince you that some 
of
them are useful for tails-greeter so that you include into its
upstream code.


TL;DR: Next time I'll check this work I'll ask you for the right git 
branch to use as a base. And I will try to apply all the advice you give 
me in this reply.




OK, great. It would be nice if we could share one single codebase
indeed. Of course, for it to not be cause problems to us this must be
done in a super nice way, that does not make the code harder to
maintain on our side (e.g. using polymorphism and specialized classes
when doable rather than if/then conditionals, etc., the usual design
patterns to achieve such results).

I see.



   My tweaks are not perfect and thus there are some doubts which I need to 
clarify
with you. Let's start.


I'm sorry it took me so long to reply. I was trying to find time to do
it as well as I wanted, and obviously I won't have enough time soon,
so I'll at least answer whatever I can quickly.

No problem. I guess we are all busy.



1. tails-greeter Rescatux branch



The branch can be found here:



https://github.com/rescatux/tails-greeter/tree/rescatux_0.40b8


First of all: as told IRL last time we met, we have a WIP branch for
a totally revamped greeter, that rewrites most of the code and totally
changes the GUI. I think you'd better base your work on that one.

I'm not sure which one is the most up-to-date, I'll let you check
freshness of:

   feature/5464-revamp-ui
   feature/7550-revamp-phase1-prototype
   feature/revamp_phase1
   feature/revamp_phase1_user_strings


I used your stable branch for jessie so that I knew it worked.
Next time I'll check this work I'll ask you for the right branch to use.


2. Configuration files for enabling / disabling features. (Python)



When I talked to Intrigeri he pointed me to:
https://git-tails.immerda.ch/whisperback/tree/whisperBack/whisperback.py?h=feature/jessie
which used in turn config.py which was loaded from different places.



As I have noticed that tails-greeter now has config.py I have just modified it 
as you
can see in:
https://github.com/rescatux/tails-greeter/commit/863b13b7378b21af70783d36b61d5a8254a74675
.


I think the "if not" construction is OK for now as a tracer bullet
approach, but at some point that'll need to be refactored IMO.


I will ask for a OOP example in the future so that I can apply it.
I guess the problem it's in the gdm's Postlogin script which it's based 
on bash. I ask myself if it can be switched to python or not.



So I have added these boolean variables:



* tails_persistence_support
* tails_show_welcome_message



which are self explanatory.



2.1. Are those names correct or do you prefer them to be written in another way?
Or with another name?


Sounds good enough and easy to rename later while refactoring if needed.

Ok.



2.2. I guess I should add more Tails specific features such as the one about
physical security.


Your call obviously.

Ok.



2.3. I personally only use the Keyboard feature. Do you think there are other 
options
which could be useful for Debian by default?


No idea (but thanks for asking :)

Perhaps the "administration password" one? Also see the ones added or
planned in our new/future Greeter, such as local time & timezone.

Ok.



3. user user instead of amnesia user .



https://github.com/rescatux/tails-greeter/commit/f04280192440db280d53414e7cde99bc3017e52d
Debian Live default user is 'user', not 'amnesia'.
So that's a clear setting that should be set by Tails.


I certainly don't mind changing the default, as long as our own use
case is still supported. And we want to switch to "user" anyway:
https://labs.riseup.net/code/issues/5655 :)

That would simplify things indeed. That way I don't have to modify the user.



4. Configuration files for enabling / disabling features. (Bash)



4.1. One important part of tails-greeter is the PostLogin script from gdm3 
which it's
written in bash.




4.2. So as I was advised by intrigeri I rewrote the different tasks into 
functions.
I modified the code so that these functions were run conditioned to some
boolean variables.


Cool. These functions need a verb in their name, given their main
responsibility implies having side-effects.

I see. I could rename them. That's not a problem.


Looks like inter-dependencies between tasks are not handled, e.g.
some bits require GATHER_GENERAL_CONFIGURATION_ENABLED=yes to work.

Not sure what you mean but I'll take a look at it when I do.



4.4. I guess you would want another bash file to be sourced if someone wants to
config / modify it to suit their needs. But which filename path exactly?


Maybe /etc/tails-greeter/PostLogin.conf or similar?


Yeah, that might do it.



5. Apart from the tails-greeter branch wit

[Tails-dev] Modifying Tails-greeter to work outside of Tails

2016-08-29 Thread adrian15
  Last year I already tried to make tails-greeter to work with (Jessie 
- 1) and I sent you an email.


https://mailman.boum.org/pipermail/tails-dev/2015-February/008051.html

  Later on I talked to intrigeri on Debconf15 and he gave me some 
advice on how I was supposed to do this.


  Anyways I'll try to summarize it:

A. I develop Rescatux ( http://www.supergrubdisk.org/rescatux/ and I 
need something at boot so that the final user can select a keyboard in a 
gui so that it gets setup and can be used.
B. tails-greeter among other things let the user choose a keyboard and 
setups it.

C. tails-greeter cannot easily be ported out of Tails.

  So, what I have been trying to do is to tweak minimally tails-greeter 
so that it meets my needs. The final purpose of these tweaks is to 
convince you that some of them are useful for tails-greeter so that you 
include into its upstream code.


  My tweaks are not perfect and thus there are some doubts which I need 
to clarify with you. Let's start.


1. tails-greeter Rescatux branch

The branch can be found here:

https://github.com/rescatux/tails-greeter/tree/rescatux_0.40b8

2. Configuration files for enabling / disabling features. (Python)

When I talked to Intrigeri he pointed me to:
https://git-tails.immerda.ch/whisperback/tree/whisperBack/whisperback.py?h=feature/jessie
which used in turn config.py which was loaded from different places.

As I have noticed that tails-greeter now has config.py I have just 
modified it as you can see in: 
https://github.com/rescatux/tails-greeter/commit/863b13b7378b21af70783d36b61d5a8254a74675 
.


So I have added these boolean variables:

* tails_persistence_support
* tails_show_welcome_message

which are self explanatory.

2.1. Are those names correct or do you prefer them to be written in 
another way? Or with another name?
2.2. I guess I should add more Tails specific features such as the one 
about physical security.
2.3. I personally only use the Keyboard feature. Do you think there are 
other options which could be useful for Debian by default?


3. user user instead of amnesia user .

https://github.com/rescatux/tails-greeter/commit/f04280192440db280d53414e7cde99bc3017e52d
Debian Live default user is 'user', not 'amnesia'.
So that's a clear setting that should be set by Tails.

4. Configuration files for enabling / disabling features. (Bash)

4.1. One important part of tails-greeter is the PostLogin script from 
gdm3 which it's written in bash.


https://github.com/rescatux/tails-greeter/commit/56b6a047f7f01dc09b85578f8df4c1542a0515d9

https://github.com/rescatux/tails-greeter/commit/b7228693581c1a15c6b2ae2dd0bfe59f963d9692

https://github.com/rescatux/tails-greeter/commit/c7c60689602fa7238e1ccc27480ecabd9bd234b6

https://github.com/rescatux/tails-greeter/commit/8735df7017279708eec8c8509be422c6c7c75157

4.2. So as I was advised by intrigeri I rewrote the different tasks into 
functions. I modified the code so that these functions were run 
conditioned to some boolean variables.


4.3. I finally changed their values so that by default only localization 
task was run.


4.4. I guess you would want another bash file to be sourced if someone 
wants to config / modify it to suit their needs. But which filename path 
exactly?


5. Apart from the tails-greeter branch with my changes, the fact that 
tails-greeter was changed from (Jessie - 1) to Jessie I also had to 
modify some files from the Debian Live project itself.


5.1.
https://github.com/rescatux/rescatux/commit/f073ad5cd60fa6e85fe71d7f75f4c494c8dd8c68

5.2. And add some new packages:

https://github.com/rescatux/rescatux/commit/e38cc70fa8cd3ddf7701137d1e4c5f28d971b928

which increase the CD size by 60 or 70 MB.

(This is more a Rescatux question than focusing to try to 'port' 
tails-greeter into Debian)


Do you know by any chance if there are any specific packages asked by 
tails-greeter dependencies which might not be needed if you only want 
localisation support ?


5.3. You seem to define metacity as compulsory. Why do we need a window 
manager if there are no windows involved? I mean... I don't see a bar 
above them to be able to move them.


Maybe what I am trying to ask you is:

Can I use another window manager such as the default one that comes in 
Rescatux / LXDE instead of metacity? Or is there anything specific on 
gdm3 or tails-greeter that needs that specific metacity window manager ?






Well, hopefully, I have not forgotten anything.

Waiting for your feedback.

Thank you.


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Testing tails-greeter in Wheezy's Debian Live

2015-02-07 Thread adrian15

Do you think I should stay subscribed?
Or do I just wait for e.g. two months so that you are not so busy and I 
try again? I guess you are trying to release an stable Tails.


Thank you for pinging back.

adrian15

El 07/02/15 a las 12:49, intrigeri escribió:

adrian15 wrote (07 Feb 2015 11:11:36 GMT) :

(I am sending this message again. The first time I sent it I received no 
response
whatsoever from tails-greeter people. [...])


Sorry for the delay, we're super busy.

Cheers,


--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


[Tails-dev] Testing tails-greeter in Wheezy's Debian Live

2014-11-25 Thread adrian15
Note: Just in case it does not make sense I'm reusing an email that I 
sent originally to Debian Live mailing list. So the first part of it 
it's addressed to Debian Live people.


Introduction

  As you might know I'm interested in the final user being able to 
choose a keyboard from a menu. And that should work in Debian Live by 
default. ( https://lists.debian.org/debian-live/2014/10/msg00056.html )


  I finally made my mind to use tails-greeter as a base for this 
specific requirement ( 
https://lists.debian.org/debian-live/2014/11/msg00041.html) and this 
email explains my findings and doubts about it.


How to test tails-greeter
--
(This is not needed because you can test it in Rescatux 0.32b3. I still 
reuse it from Debian Live mailing list original email so that you see 
what the problems when you want to use your greeter as-is in Wheezy 
Debian Live).


  So, here there are the needed steps for making tails-greeter to work 
in a Wheezy LXDE's Debian Live CD (Rescatux 0.32b2 specifically). As 
it's LXDE based you might need to adapt the lightdm stop of another dm.


  These instructions are meant for using them once your original Debian 
Live CD has booted. They are not meant for setting up your Debian Live 
config and rebuild it.


1. Create:

/etc/apt/sources.list.d/tails.list
with:
deb http://deb.tails.boum.org/ 1.2 main

2. Run:
apt-get update

3. apt-get install tails-greeter
When prompted choose gdm3 instead of the default lightdm

4.

Create a fake live-persist at:
/usr/local/sbin/live-persist
with:
#!/bin/bash
exit 0
and give it execution permissions:
chmod +x /usr/local/sbin/live-persist

5. Edit default user
Edit:
/usr/lib/python2.7/dist-packages/tailsgreeter/config.py
and change
LUSER = 'amnesia'
to:
LUSER = 'user'

6. Apply changes with (probably better at CTRL+ALT+F1):

service lightdm stop
service gdm3 start

7. Be patient.

At the bottom you can change the keyboard then you click on Login button

8. The usual desktop appears and you have keyboard setup !

Questions about tails-greeter
-

1) Both:

Supported language codes: /usr/share/tails-greeter/language_codes
Default language code: /usr/share/tails-greeter/default_languagecodes

are saved at Tails build time (according to: 
/usr/lib/python2.7/dist-packages/tailsgreeter/config.py file).


As I see these files are being generated when tails-greeter package is 
built.


What I am to focus right now is in language_codes (all the possible ones).
According to:
https://git-tails.immerda.ch/greeter/tree/debian/rules?id=tails-greeter_0.8.5#n16
you seem to build your list based on:
/usr/share/i18n/SUPPORTED
.

My questions about language_codes are:

1.1) Are you excluding some keyboards on purpose or not ? If so, why? 
(Sorry I'm not very good at perl).
1.2) Do the tails-greeter buil-dependencies ensure that all the packages 
that fullfill the different keyboard layouts at: 
/usr/share/i18n/SUPPORTED/ are installed previous to the build?


My questions about default langcodes are:

1.3)

https://git-tails.immerda.ch/greeter/tree/default_langcodes?id=tails-greeter_0.8.5

Is there any rationale for choosing these ones over the rest of them?

About my fork and more questions about tails-greeter


So I have made a tails-greeter fork so that it could work adapt and use 
it right now in Rescatux.


1) You can find the fork at:

https://github.com/adrian15/tails-greeter/tree/rescatux_0.32

2) You can try the fork by testing the latest Rescatux 0.32 beta 3 here:

http://www.supergrubdisk.org/2014/11/24/rescatux-0-32-beta-3-released/

3) How do you want to share source code?
3.1) At runtime thanks to a variable that depends on finding exclusive 
files found at Tails live cd? (Kind of what I draft on my fork).
3.2) With a build time variable that generates one type of package or 
antoher?
3.3) Trying to split the greeter into two parts, two packages (backend + 
frontend) so that I only have to code my own frontend different than 
ours but share the languages, country and keyboard layout algorithms?

3.4) Maybe another approach?

4) While doing my tests I have noticed an error similar to this one (I 
would have to reproduce it to give you the exact error):


locale: Cannot Set LC_ALL to default locale: No such file or directory.

if try to run gparted from a root console.

If I checked with locale I saw that locale was something like:

en_US.ansi_x3

That's why I added the two commands for forcing the generation of the 
used locale.


I'm asking myself if it's a problem because I use libc6 from jessie 
instead of wheezy or if it's something extra that your greeter does that 
I never came across.


5) Is there a way in your glade translation to replace Tails with a 
variable so that when the distro is not Tails you do not have to 
translate it all over again but just change the variable value ?


6) I would like to rewrite the greeter