[Tails-dev] alertas bursatiles potentes, 86.5% efectivas, gratis via sms
24option Si no puede ver este correo o está usando un dispositivo móvil, por favor, haga clic aquí ( Link -> http://option.go2jump.org/SH1BefZ ) . ( Link -> http://option.go2jump.org/SH1BefZ ) ¡Alertas bursátiles potentes dondequiera esté! Cuando aparezcan oportunidades en el mercado, usted recibirá un SMS con las mejores alertas profesionales del sector: Fácil de utilizar Algoritmos avanzados Recomendado por los mejores analistas del mercado ; ¡Mejore sus operaciones con nuestro servicio SMS de alertas bursátiles profesionales! ( Link -> http://option.go2jump.org/SH1BefZ ) * Se aplican términos y condiciones Advertencia general de riesgo: Operar con opciones binarias conlleva un alto nivel de riesgo y puede dar como resultado la pérdida de toda su inversión. Como tal, las opciones binarias podrían no ser apropiadas para todos los inversores. No debe invertir capital que no pueda permitirse perder. Antes de decidirse a operar, debe ser consciente de todos los riesgos asociados a las operaciones con opciones binarias, y buscar el consejo de un asesor financiero fiable e independiente. Bajo ninguna circunstancia tendremos resposabilidad sobre ninguna persona o entidad de (a)las pérdidas o daños al completo o en parte causados por, como resultado de, o relacionados con cualquier transacción relacionada con las opciones binarias o (b) cualquier daño directo, indirecto, especial, a consecuencia de o casual de ninguna clase. Aplicación de términos & condiciones, consulte la página web completa para obtener más información ( Link -> http://option.go2jump.org/SH1BefZ ) . 24option.com es una firma perteneciente y operada por Rodeler Limited, una compañía de servicios financieros registrada en Chipre (HE312820) y autorizada y regulada por la Cyprus Securities Exchange Commission bajo la licencia número 207/13. Rodeler Limited tiene su sede en 39 Kolonakiou Street, FREMA PLAZA, First Floor, 4103 Ayios Athanasios, Limassol Cyprus. Si quiere cancelar la suscripción a este correo, por favor, haga clic aquí ( Link -> http://option.go2jump.org/SH1BefZ ) Agréganos a tu lista de contactos Información de Contacto ( Link -> http://82754.track.tstes.net/track/click?u=vcard=38323735343a383a343a303a303a30=12957=be409637da1b9c3167ec9a1b5c659e11 ) Para desuscribirse de nuestra lista haga ( Link -> http://82754.track.tstes.net/track/click?u=unsubscribe=38323735343a383a343a303a303a30=12957=be409637da1b9c3167ec9a1b5c659e11 ) ___ 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] [GSoC] Tails Server - status report 3
Hi everyone, this is the third status report on the Tails Server GSoC project. I had to omit the previous report because personal difficulties were getting in the way. So here is what I achieved in the last four weeks: * Revamp the GUI * Replace the status panel with a config panel * Add a loading window * Implement the persistence feature * Refactor the code * Many more changes in the code, you can look at my commit messages if you want more details * Keep discussing the design of the GUI on the Tails-UX mailing list The prototype is actually working now. The persistence feature works without dirty hacks now, because anonym kindly implemented a new feature in Tails' persistence (regular files can be bind-mounted now). Because Tails Server now relies on this feature, it will only work properly in this patched Tails version. I will integrate Tails Server in this branch and send a link to a nightly ISO image on tor-dev and tails-dev in the next few days, so you can test it. Next up is some more polishing of the GUI and writing a short documentation to be able to do some initial user tests. And then there are still a lot of features to implement, like autostarting the services, onion address regeneration, client authentication (not necessarily in scope of the GSoC, but I want it anyway), and many more. And I will have to refactor the code some more. Cheers! ___ 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] Persistent torrc [Was: Tails Server: updated plan and GSoC!]
segfault: > I just noticed that actually I do not parse the config files every time > I need an option value. I only read the value the first time I need it > and then store it in a variable. I do write to the config files > everytime the value is set though. > I can test later how much the performance impact of parsing the config > files every time. I'd be surprised if it was noticeable. For the record, I'd be willing to pay even a 1 second delay to get the nice property of never having state out of sync and thus avoid a whole class of subtle bugs. :) Cheers! ___ 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] Persistent torrc [Was: Tails Server: updated plan and GSoC!]
anonym: [...] >> Just to clarify things: Currently Tails Server does have a configuration >> file for each service (which is made persistent if the service is >> persistent). Those are currently in /usr/share/tails-server/options/, >> e.g. /usr/share/tails-server/options/mumble. But I only store options in >> there which are not part of some other configuration file, in order to >> prevent redundancy and inconsistent states. So everytime Tails Server >> needs the value of an user option, the corresponding configuration file >> (e.g. /etc/mumble-server.ini for the server password) is parsed. >> (But the persistent option is not stored anywhere else, so it is stored >> in this internal options file.) >> >> Please tell me if you see any problems with this approach. > > Yes, this is exactly what we had very good reason to agree to do before, > so it's awesome! I just noticed that actually I do not parse the config files every time I need an option value. I only read the value the first time I need it and then store it in a variable. I do write to the config files everytime the value is set though. I can test later how much the performance impact of parsing the config files every time. ___ 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] Persistent torrc [Was: Tails Server: updated plan and GSoC!]
segfault:
> anonym:
>> segfault:
>>> anonym:
segfault:
> anonym:
[...]
However, if possible, let's try an approach that doesn't rely on this,
ok? But I still guess you'd like to have this for the persistent
configuration/date for services (i.e. the non-Tails Server bits, e.g.
mumble-server's database and similar) as we've discussed before?
>>>
>>> ACK. I agree that the other options are better than making the torrc
>>> persistent. But I still need to make single configuration files
>>> persistent (e.g. /etc/mumble-server.ini).
>>
>> Ok, I created #11533 [0] to track this and pushed a branch with a first
>> attempt at patching live-boot. I haven't tested it, so please do! If it
>> doesn't work, perhaps the patch gives you enough context to fix it
>> yourself (it should be confined to `activate_custom_mounts()`)? :) But
>> please don't waste time on it -- this code is my own baby Frankenstein.
>>
>> [0] https://labs.riseup.net/code/issues/11533
>
> I tested it and it works! Thanks so much for implementing this :)
Wow, cool! Next step is to properly upstream it, then.
[...]
>> # add_onion
>>
>> By using stem to communicate with Tor over the control port/socket to
>> add the hidden services, just like onionshare does (which would be a
>> good source for inspiration, code-wise), you don't need any torrc
>> persistence just like in the previous approach. This is probably the
>> most "proper" solution of these three (and requires implementing less
>> logic on our side), and it might even be the easiest after you've
>> familiarized yourself with the API. This seems like the best option to
>> me.
>
> Right. I didn't see this option either, but I think this would work too.
> I will try this :)
It's ~new, which might explain it. Any way, I really hope this approach
works out since it looks the cleanest of those presented so far!
>>>
>>> I'm positive that this will work. But I think I will use the old
>>> create_hidden_service() [1] instead of the new
>>> create_ephemeral_hidden_service() [2], because the latter does not
>>> create a hidden service directory, which I need to make the service
>>> persistent. Also, only create_hidden_service() supports client
>>> authentication, which I want to support.
>>
>> Sounds great!
>
> Unfortunately, it seems like the create_hidden_service() won't work with
> the sandboxed Tor we use, because the sandbox prevents Tor to access the
> hidden service directory, which create_hidden_service() needs to access.
> Micah Lee ran into the same problem with OnionShare [1] (He fixed it by
> using create_ephemeral_hidden_service(), but I need the hidden service
> directory for persistence, so I think this is no option for me).
>
> [1] https://github.com/micahflee/onionshare/issues/179
That's unfortunate. :/ I was gonna suggest to try SETCONF (via whatever
interface stem has for it) instead, but I guess it's affected by the
same issue. Otherwise, maintaining it with SETCONF and RESETCONF (and
SAVECONF so restarting tor during the same session doesn't drop the
HSes) might be easier and prettier than the regex soup I imagine for...
> For now I'm back to the "# Maintain HiddenService{Dir,Port} lines in
> /etc/tor/torrc" option, which is working fine.
... this approach. Still, it's good enough, so I think you should just
stick with this. Just try to abstract these parts in the code so that it
will be easy to change implementation to add_onion in the future.
Cheers!
___
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.
