Re: [systemd-devel] Confusing journal information - journal size

2015-07-20 Thread David Sommerseth 
On 20/07/15 15:31, Anne Mulhern wrote:
 - Original Message -
 From: Colin Guthrie gm...@colin.guthr.ie
 To: systemd-devel@lists.freedesktop.org
 Sent: Monday, July 20, 2015 5:38:38 AM
 Subject: Re: [systemd-devel] Confusing journal information - journal size

 David Sommerseth wrote on 17/07/15 14:28:
 On 17/07/15 13:31, Mantas Mikulėnas wrote:
 On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com
 mailto:dav...@redhat.com wrote:


 Hi,

 I'm looking through some journals now, and even though I've seen it a
 few times I haven't thought about it until now.

systemd-journal[1151]: Runtime journal is using 8.0M (max allowed
  4.0G, trying to leave 4.0G free of 63.7G available →
  current limit 4.0G).

 Could this line be cleaned up so you don't have to look up a man page
 to
 try to figure out what this really means?  Here's my uneducated guess
 and confusion of this line:

 * Runtime journal is using 8.0M
   - Okay, so currently the journal uses 8MB of disk-space.  No
   problem.

 * max allowed 4.0G
   - Okay, so the journal should not grow beyond 4GB, makes sense.  No
 problem.

 * trying to leave 4.0G free of 63.7G available
   - Uhm, what!? So it will grow until there is 4GB left on the
 filesystem?  Not so okay.


 It chooses the /smallest/ limit, not largest. (Common sense...) For
 example, if you had only 5 GB space available, the journal would not
 grow beyond 1 GB.
  

 * current limit 4.0G
   - Ehh ... okay ... so make up your mind, please!  So will the
 journal grow until 4GB or 59.7GB.


 This *is* it making up its mind: min(limit 1, limit 2) → resulting limit

 But then I looked into /var/log/journal ...

   # du --si -s /var/log/journal/
   4.3G  /var/log/journal/

 I do see that both system,journal and user-UID.journal are both 8.4MB,
 and from that I can guess what the log entry tried to tell me with
 Runtime journal ... but how is /that/ information useful for me,
 from
 a sys-admin point of view?


 Runtime here means /run, as opposed to persistent in /var. They have
 separately configurable limits, since /run is in RAM and /var is usually
 on disk. (Though, I'm not entirely sure what purpose the runtime journal
 even serves, when /var is available.)

 Fair enough.  But you are missing my point.

 How this information is presented do require some detail knowledge of
 the journal.  Don't think like a developer who have poked at the journal
 code.  Think like a sys-admin who looks through the logs looking for
 issues.  Then you want to have the answer straight in your face, not
 needing to go elsewhere to read about these things.  In fact most admins
 will probably have forgotten what they were going to look for when they
 move their eyes of the log data.

 If it is considered important information, fine.  But present it in a
 far more understandable way for those who just uses the journal.  Right
 now, I'm not surprised if most sys-admins read that line as useless
 gibberish - Yeah, yeah, journal will waste some space on my drive.

 Yeah, I can't disagree with David. Not sure how best to tidy it up, but
 some rework would definitely be nice.

 Col

 
 After seeing the explanation, the best complete and correct (AFAICT) 
 formulation I could come up with was,
 
 Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total 
 memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G)
 
 which is compelled to use math speak for clarity and succinctness.
 
 Dunno how happy most sys-admins would be with that.
 
 - mulhern

But is all that information really needed?

If I try to see this from a sys-admin point of view there are two
numbers which are important to me: 1) Current state 2) Final journal
limit size.  From how I see it, how the journal code ends up with a
certain number is only useful when you're developing/debugging the
journal.  Remember: Less is more.


--
kind regards,

David Sommerseth
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Confusing journal information - journal size

2015-07-20 Thread David Sommerseth 
On 20/07/15 17:49, Colin Guthrie wrote:
 David Sommerseth wrote on 20/07/15 16:29:
 On 20/07/15 15:31, Anne Mulhern wrote:
[...snip...]

 After seeing the explanation, the best complete and correct (AFAICT) 
 formulation I could come up with was,

 Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total 
 memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G)

 which is compelled to use math speak for clarity and succinctness.

 Dunno how happy most sys-admins would be with that.

 - mulhern

 But is all that information really needed?

 If I try to see this from a sys-admin point of view there are two
 numbers which are important to me: 1) Current state 2) Final journal
 limit size.  From how I see it, how the journal code ends up with a
 certain number is only useful when you're developing/debugging the
 journal.  Remember: Less is more.
 
 Well I guess you could just log something like:
 
 Runtime journal is using 8.0M (see 'journalctl status' for more info)
 
 Then you add a journalctl status verb that explained the current
 status of journal (e.g. number of files on disk and in memory, how the
 file size and rotation will work etc)
 
 
 That might be more practically useful, but it won't explain things as
 calculated at the time that log entry was created, so can I suggest that
 an additional _CALCULATION field (or soemthing similarly named) is
 added into that log message that is not shown by default but is stored)
 so that the typical administrator looking at the log out put will not
 see the detail, but it is logged.
 
 The journalctl status command could even pull out the last messages in
 the journal (via it's message id) and then get the _CALCULATION field
 and show it in a nice, verbose way to the user.
 
 That keeps it simple by default but has all the juicy details there
 should they be needed.
 
 Just a thought.

+1 ... This makes a lot of sense!  I like the journalctl status
approach, as that can provide even more details with some more
explanations when needed.  But I see the benefits of having more
hidden fields with details.


--
kind regards,

David Sommerseth
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Confusing journal information - journal size

2015-07-17 Thread David Sommerseth 
On 17/07/15 13:31, Mantas Mikulėnas wrote:
 On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com
 mailto:dav...@redhat.com wrote:
 
 
 Hi,
 
 I'm looking through some journals now, and even though I've seen it a
 few times I haven't thought about it until now.
 
systemd-journal[1151]: Runtime journal is using 8.0M (max allowed
  4.0G, trying to leave 4.0G free of 63.7G available →
  current limit 4.0G).
 
 Could this line be cleaned up so you don't have to look up a man page to
 try to figure out what this really means?  Here's my uneducated guess
 and confusion of this line:
 
 * Runtime journal is using 8.0M
   - Okay, so currently the journal uses 8MB of disk-space.  No problem.
 
 * max allowed 4.0G
   - Okay, so the journal should not grow beyond 4GB, makes sense.  No
 problem.
 
 * trying to leave 4.0G free of 63.7G available
   - Uhm, what!? So it will grow until there is 4GB left on the
 filesystem?  Not so okay.
 
 
 It chooses the /smallest/ limit, not largest. (Common sense...) For
 example, if you had only 5 GB space available, the journal would not
 grow beyond 1 GB.
  
 
 * current limit 4.0G
   - Ehh ... okay ... so make up your mind, please!  So will the
 journal grow until 4GB or 59.7GB.
 
 
 This *is* it making up its mind: min(limit 1, limit 2) → resulting limit
 
 But then I looked into /var/log/journal ...
 
   # du --si -s /var/log/journal/
   4.3G  /var/log/journal/
 
 I do see that both system,journal and user-UID.journal are both 8.4MB,
 and from that I can guess what the log entry tried to tell me with
 Runtime journal ... but how is /that/ information useful for me, from
 a sys-admin point of view?
 
 
 Runtime here means /run, as opposed to persistent in /var. They have
 separately configurable limits, since /run is in RAM and /var is usually
 on disk. (Though, I'm not entirely sure what purpose the runtime journal
 even serves, when /var is available.)

Fair enough.  But you are missing my point.

How this information is presented do require some detail knowledge of
the journal.  Don't think like a developer who have poked at the journal
code.  Think like a sys-admin who looks through the logs looking for
issues.  Then you want to have the answer straight in your face, not
needing to go elsewhere to read about these things.  In fact most admins
will probably have forgotten what they were going to look for when they
move their eyes of the log data.

If it is considered important information, fine.  But present it in a
far more understandable way for those who just uses the journal.  Right
now, I'm not surprised if most sys-admins read that line as useless
gibberish - Yeah, yeah, journal will waste some space on my drive.


--
kind regards,

David Sommerseth
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Confusing journal information - journal size

2015-07-17 Thread David Sommerseth 

Hi,

I'm looking through some journals now, and even though I've seen it a
few times I haven't thought about it until now.

   systemd-journal[1151]: Runtime journal is using 8.0M (max allowed
 4.0G, trying to leave 4.0G free of 63.7G available →
 current limit 4.0G).

Could this line be cleaned up so you don't have to look up a man page to
try to figure out what this really means?  Here's my uneducated guess
and confusion of this line:

* Runtime journal is using 8.0M
  - Okay, so currently the journal uses 8MB of disk-space.  No problem.

* max allowed 4.0G
  - Okay, so the journal should not grow beyond 4GB, makes sense.  No
problem.

* trying to leave 4.0G free of 63.7G available
  - Uhm, what!? So it will grow until there is 4GB left on the
filesystem?  Not so okay.

* current limit 4.0G
  - Ehh ... okay ... so make up your mind, please!  So will the
journal grow until 4GB or 59.7GB.


But then I looked into /var/log/journal ...

  # du --si -s /var/log/journal/
  4.3G  /var/log/journal/

I do see that both system,journal and user-UID.journal are both 8.4MB,
and from that I can guess what the log entry tried to tell me with
Runtime journal ... but how is /that/ information useful for me, from
a sys-admin point of view?

My point is ... you're providing too much information and you need to
understand more underlying things about the journal.  Simply state how
much disk-space the journal uses now and how much it will grow.  Period.
 Don't do any we can grow until size X, but decided to grow to Y
instead information.

And yes, I deliberately didn't look into any man pages or code this
time.  Because this is what I believe most sys-admins will do: guess.


--
kind regards,

David Sommerseth
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] ask-password: Add --echo to enable echoing the user input

2014-10-03 Thread David Sommerseth 
Programs such as OpenVPN may use ask-password for not only retrieving
passwords, but also usernames.  Masking usernames with * seems just silly.

 v2 - Don't mess with termios flags, instead print the input
  instead of an asterix.  Resolves issues with backspace
  and TAB input.

 v3 - Renamed 'do_echo' variables and argument to 'echo'.  Also
  modified the ask_password_{tty,agent,auto} API instead of
  additional wrapper functions.
---
 man/systemd-ask-password.xml|  9 +
 src/ask-password/ask-password.c | 12 ++--
 src/cryptsetup/cryptsetup.c |  4 ++--
 src/firstboot/firstboot.c   |  4 ++--
 src/shared/ask-password-api.c   | 12 
 src/shared/ask-password-api.h   |  6 +++---
 src/tty-ask-password-agent/tty-ask-password-agent.c |  5 +++--
 7 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml
index ce0ac3d..bfe646f 100644
--- a/man/systemd-ask-password.xml
+++ b/man/systemd-ask-password.xml
@@ -127,6 +127,15 @@
 /varlistentry
 
 varlistentry
+termoption--echo/option/term
+
+listitemparaEcho the user input
+instead of masking it.  This is useful
+when using systemd-ask-password to
+query for usernames./para/listitem
+/varlistentry
+
+varlistentry
 termoption--no-tty/option/term
 
 listitemparaNever ask for password
diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index 5c37cff..54acace 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -45,6 +45,7 @@
 static const char *arg_icon = NULL;
 static const char *arg_id = NULL;
 static const char *arg_message = NULL;
+static bool arg_echo = false;
 static bool arg_use_tty = true;
 static usec_t arg_timeout = DEFAULT_TIMEOUT_USEC;
 static bool arg_accept_cached = false;
@@ -56,6 +57,7 @@ static void help(void) {
  -h --help  Show this help\n
 --icon=NAME Icon name\n
 --timeout=SEC   Timeout in sec\n
+--echo  Do not mask the user input. Used when 
asking for usernames\n
 --no-ttyAsk question via agent even on TTY\n
 --accept-cached Accept cached passwords\n
 --multiple  List multiple passwords if available\n
@@ -68,6 +70,7 @@ static int parse_argv(int argc, char *argv[]) {
 enum {
 ARG_ICON = 0x100,
 ARG_TIMEOUT,
+ARG_ECHO,
 ARG_NO_TTY,
 ARG_ACCEPT_CACHED,
 ARG_MULTIPLE,
@@ -78,6 +81,7 @@ static int parse_argv(int argc, char *argv[]) {
 { help,  no_argument,   NULL, 'h'   
},
 { icon,  required_argument, NULL, ARG_ICON  
},
 { timeout,   required_argument, NULL, ARG_TIMEOUT   
},
+{ echo,  no_argument,   NULL, ARG_ECHO  
},
 { no-tty,no_argument,   NULL, ARG_NO_TTY
},
 { accept-cached, no_argument,   NULL, ARG_ACCEPT_CACHED 
},
 { multiple,  no_argument,   NULL, ARG_MULTIPLE  
},
@@ -109,6 +113,10 @@ static int parse_argv(int argc, char *argv[]) {
 }
 break;
 
+case ARG_ECHO:
+arg_echo = true;
+break;
+
 case ARG_NO_TTY:
 arg_use_tty = false;
 break;
@@ -160,7 +168,7 @@ int main(int argc, char *argv[]) {
 if (arg_use_tty  isatty(STDIN_FILENO)) {
 char *password = NULL;
 
-if ((r = ask_password_tty(arg_message, timeout, NULL, 
password)) = 0) {
+if ((r = ask_password_tty(arg_message, timeout, arg_echo, 
NULL, password)) = 0) {
 puts(password);
 free(password);
 }
@@ -168,7 +176,7 @@ int main(int argc, char *argv[]) {
 } else {
 char **l;
 
-if ((r = ask_password_agent(arg_message, arg_icon, arg_id, 
timeout, arg_accept_cached, l)) = 0) {
+if ((r = ask_password_agent(arg_message, arg_icon, arg_id, 
timeout, arg_echo, arg_accept_cached, l)) = 0) {
 char **p;
 
 STRV_FOREACH(p, l) {
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 94570eb..ed4866e

Re: [systemd-devel] [PATCH] tty-ask-password-agent: Allow user input to be echoed

2014-10-02 Thread David Sommerseth 
On 02/10/14 14:14, Zbigniew Jędrzejewski-Szmek wrote:
 On Tue, Sep 30, 2014 at 04:24:49PM +0200, Tom Gundersen wrote:
 Hi David,

 Just a quick follow up on these two patches (sorry for the delay).

 On the one hand, we want this interface to be very basic and should
 probably not something we should extend to cover all sorts of things.
 On the other hand, this usecase (and similar ones where you have a
 real password, but maybe it is a one-time password, so you don't care
 about hiding it) seems very natural, and the patches are simple.

 I'll leave it up to Lennart to decide.
 
 Yes, the patch looks OK, but like with the other one, please
 rename do_echo to echo, and add an extra argument to the function instead
 of adding a second function.

Thanks a lot for the reviews!  I'll submit new patches in the coming days.

Just one detail though.  When changing the function API, the needed
changes will become more intrusive.  I tried to keep the change-set as
small as possible and preserve a clear use case through the function
names.  I also feel that the 'echo' flag in password related functions
shouldn't be hidden behind a true/false argument to a function, as it is
a big difference in the behaviour from a user's perspective.  But that
is my personal preference.  I will do what has been requested in the
reviews.


--
kind regrards,

David Sommerseth

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input

2014-09-19 Thread David Sommerseth 
On 18/09/14 18:02, Colin Guthrie wrote:
 I'd rather the ability to make a single request and have the agent ask
 for all credentials and reply once rather than looping over both
 separately however.

+1 ... But I'll have to say that this will require a bit of re-designing
old cold paths in OpenVPN.  But it is doable.  Anyhow, AFAIK (and nobody
have told me otherwise in this ML), such an approach does not exist.
I've heard vague rumours about a new implementation using dbus, but not
seen any clear evidence of that yet.

Right now (which is the situation I try to solve), it is the issue of
avoiding masking username which is my primary goal, as it seems
ask-password is the only way to get user input via systemd.  When an
agreed approach can be reached, I can adopt OpenVPN and submit the
needed patches to that community.

When systemd have landed on a better approach, I'll be happy to include
patches in OpenVPN to go in that direction.


All this said, I'll post another updated to this patch soonish.  When
going through the tty-ask-password-agent, the masking still happens.
I'm digging into that now.


--
kind regards,

David Sommerseth

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] tty-ask-password-agent: Allow user input to be echoed

2014-09-19 Thread David Sommerseth 
This is a continuation of the patch ask-password: Add --do-echo to enable
echoing the user input.

This allows user input going via the ask-password-agent to be echoed
as well, if the --do-echo argument is provided to systemd-ask-password.

Again it was preferred to add a new function, ask_password_agent_echo(),
over modifying the ask_password_agent() API to make the use case clearer
and keep backwards compatibility with applications depending on
ask_password_agent().

Signed-off-by: David Sommerseth dav...@redhat.com
---
 src/ask-password/ask-password.c |  5 -
 src/shared/ask-password-api.c   | 16 +++-
 src/shared/ask-password-api.h   |  2 ++
 src/tty-ask-password-agent/tty-ask-password-agent.c |  6 --
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index c77cc66..c6744b9 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -179,7 +179,10 @@ int main(int argc, char *argv[]) {
 } else {
 char **l;
 
-if ((r = ask_password_agent(arg_message, arg_icon, arg_id, 
timeout, arg_accept_cached, l)) = 0) {
+r = arg_do_echo ? ask_password_agent_echo(arg_message, 
arg_icon, arg_id, timeout, arg_accept_cached, l)
+: ask_password_agent(arg_message, arg_icon, arg_id, 
timeout, arg_accept_cached, l);
+
+if (r = 0) {
 char **p;
 
 STRV_FOREACH(p, l) {
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index 283bfc2..39c122e 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -311,12 +311,13 @@ fail:
 return r;
 }
 
-int ask_password_agent(
+static int __ask_password_agent(
 const char *message,
 const char *icon,
 const char *id,
 usec_t until,
 bool accept_cached,
+bool do_echo,
 char ***_passphrases) {
 
 enum {
@@ -378,10 +379,12 @@ int ask_password_agent(
 PID=PID_FMT\n
 Socket=%s\n
 AcceptCached=%i\n
+DoEcho=%i\n
 NotAfter=USEC_FMT\n,
 getpid(),
 socket_name,
 accept_cached ? 1 : 0,
+do_echo ? 1 : 0,
 until);
 
 if (message)
@@ -557,6 +560,17 @@ finish:
 return r;
 }
 
+int ask_password_agent(const char *message, const char *icon, const char *id,
+   usec_t until, bool accept_cached, char ***_passphrases) 
{
+return __ask_password_agent(message, icon, id, until, accept_cached, 
false, _passphrases);
+}
+
+int ask_password_agent_echo(const char *message, const char *icon, const char 
*id,
+usec_t until, bool accept_cached, char 
***_passphrases) {
+return __ask_password_agent(message, icon, id, until, accept_cached, 
true, _passphrases);
+}
+
+
 int ask_password_auto(const char *message, const char *icon, const char *id,
   usec_t until, bool accept_cached, char ***_passphrases) {
 assert(message);
diff --git a/src/shared/ask-password-api.h b/src/shared/ask-password-api.h
index c3dde63..d467398 100644
--- a/src/shared/ask-password-api.h
+++ b/src/shared/ask-password-api.h
@@ -28,6 +28,8 @@ int ask_password_tty_echo(const char *message, usec_t until, 
const char *flag_fi
 
 int ask_password_agent(const char *message, const char *icon, const char *id,
usec_t until, bool accept_cached, char ***_passphrases);
+int ask_password_agent_echo(const char *message, const char *icon, const char 
*id,
+usec_t until, bool accept_cached, char 
***_passphrases);
 
 int ask_password_auto(const char *message, const char *icon, const char *id,
   usec_t until, bool accept_cached, char ***_passphrases);
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c 
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 8a02fb0..90bbd1e 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -214,7 +214,7 @@ static int parse_password(const char *filename, char 
**wall) {
 _cleanup_free_ char *socket_name = NULL, *message = NULL, *packet = 
NULL;
 uint64_t not_after = 0;
 unsigned pid = 0;
-bool accept_cached = false;
+bool accept_cached = false, do_echo = false;
 
 const ConfigTableItem items[] = {
 { Ask, Socket,   config_parse_string,   0, 
socket_name   },
@@ -222,6 +222,7 @@ static int parse_password(const char *filename, char 
**wall) {
 { Ask, Message,  config_parse_string,   0, message
   },
 { Ask, PID

Re: [systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input

2014-09-18 Thread David Sommerseth 
On 17/09/14 17:52, Jóhann B. Guðmundsson wrote:
 
 On 09/17/2014 12:26 PM, David Sommerseth wrote:
 Hi,

 I've been playing with the systemd feature enabled in OpenVPN.  And I
 propose this change to systemd-ask-password to avoid masking usernames.
   I tried looking for alternative ways querying for usernames through
 systemd without finding a good solution.

 This patch has been tested locally on a slightly modified OpenVPN build
 which calls systemd-ask-password with --do-echo when it queries the user
 for usernames.

 If there are better ways how to solve this, please let me know and I'll
 go that path instead.


 
 Should this not be fixed upstream openvpn?

OpenVPN have already implemented support for systemd.  The issue is when
OpenVPN starts a config file where will ask the user for username and
password.  Without this systemd patch the result is that the username
isn't displayed as plain text but a bunch of stars - and kicking off
openvpn via systemctl fails.

Based on my systemd knowledge, the alternative is to _not_ use
systemd-ask-password at all, which makes it harder to start openvpn
tunnels via systemctl or at boot time.  And that will not be well
received among OpenVPN users.

If you think we're doing it wrong in OpenVPN, I'm willing to fix this.
As more and more distros move over to systemd, this is something we see
we need to fix in OpenVPN.


--
kind regards,

David Sommerseth

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input

2014-09-17 Thread David Sommerseth 

Hi,

I've been playing with the systemd feature enabled in OpenVPN.  And I
propose this change to systemd-ask-password to avoid masking usernames.
 I tried looking for alternative ways querying for usernames through
systemd without finding a good solution.

This patch has been tested locally on a slightly modified OpenVPN build
which calls systemd-ask-password with --do-echo when it queries the user
for usernames.

If there are better ways how to solve this, please let me know and I'll
go that path instead.


--
kind regards,

David Sommerseth

From 3d174f1bf39c9690eb602b2dd2c79cf6ae6b0be1 Mon Sep 17 00:00:00 2001
From: David Sommerseth dav...@redhat.com
Date: Fri, 12 Sep 2014 11:30:41 +0200
Subject: [PATCH] ask-password: Add --do-echo to enable echoing the user input

OpenVPN may use ask-password for not only retrieving passwords, but
also usernames.  Masking usernames with * seems just silly.

This patch adds a new function ask_password_tty_echo() which will
echo the user input.  Adding another function was preferred over
adding a flag in ask_password_tty(), to make the functionality
clearer and to avoid breaking programs depending on
ask_password_tty().

 v2 - Don't mess with termios flags, instead print the input
  instead of an asterix.  Resolves issues with backspace
  and TAB input.

---
 src/ask-password/ask-password.c | 13 -
 src/shared/ask-password-api.c   | 20 ++--
 src/shared/ask-password-api.h   |  1 +
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index 5c37cff..c77cc66 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -45,6 +45,7 @@
 static const char *arg_icon = NULL;
 static const char *arg_id = NULL;
 static const char *arg_message = NULL;
+static bool arg_do_echo = false;
 static bool arg_use_tty = true;
 static usec_t arg_timeout = DEFAULT_TIMEOUT_USEC;
 static bool arg_accept_cached = false;
@@ -56,6 +57,7 @@ static void help(void) {
  -h --help  Show this help\n
 --icon=NAME Icon name\n
 --timeout=SEC   Timeout in sec\n
+--do-echo   Do not mask the user input. Used when asking for usernames\n
 --no-ttyAsk question via agent even on TTY\n
 --accept-cached Accept cached passwords\n
 --multiple  List multiple passwords if available\n
@@ -68,6 +70,7 @@ static int parse_argv(int argc, char *argv[]) {
 enum {
 ARG_ICON = 0x100,
 ARG_TIMEOUT,
+ARG_DO_ECHO,
 ARG_NO_TTY,
 ARG_ACCEPT_CACHED,
 ARG_MULTIPLE,
@@ -78,6 +81,7 @@ static int parse_argv(int argc, char *argv[]) {
 { help,  no_argument,   NULL, 'h'   },
 { icon,  required_argument, NULL, ARG_ICON  },
 { timeout,   required_argument, NULL, ARG_TIMEOUT   },
+{ do-echo,   no_argument,   NULL, ARG_DO_ECHO   },
 { no-tty,no_argument,   NULL, ARG_NO_TTY},
 { accept-cached, no_argument,   NULL, ARG_ACCEPT_CACHED },
 { multiple,  no_argument,   NULL, ARG_MULTIPLE  },
@@ -109,6 +113,10 @@ static int parse_argv(int argc, char *argv[]) {
 }
 break;
 
+case ARG_DO_ECHO:
+arg_do_echo = true;
+break;
+
 case ARG_NO_TTY:
 arg_use_tty = false;
 break;
@@ -160,7 +168,10 @@ int main(int argc, char *argv[]) {
 if (arg_use_tty  isatty(STDIN_FILENO)) {
 char *password = NULL;
 
-if ((r = ask_password_tty(arg_message, timeout, NULL, password)) = 0) {
+r = arg_do_echo ? ask_password_tty_echo(arg_message, timeout, NULL, password)
+: ask_password_tty(arg_message, timeout, NULL, password);
+
+if (r = 0) {
 puts(password);
 free(password);
 }
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index 8d03f4a..283bfc2 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -49,9 +49,10 @@ static void backspace_chars(int ttyfd, size_t p) {
 }
 }
 
-int ask_password_tty(
+static int __ask_password_tty(
 const char *message,
 usec_t until,
+bool do_echo,
 const char *flag_file,
 char **_passphrase) {
 
@@ -218,7 +219,7 @@ int ask_password_tty(
 passphrase[p++] = c;
 
 if (!silent_mode  ttyfd = 0