Changing the primary group
Hi, I am looking for something like usermod -g on desktop. Is it possible to achieve this feature? There are workarounds like adding a group and then removing the previous, etc, but it is suboptimal. Cheers, L. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On Tue, Feb 17, 2015 at 5:16 AM, Joshua Judson Rosen wrote: > On 02/15/2015 06:06 AM, Steven Honeyman wrote: >> >> On 15 February 2015 at 07:38, Explorer wrote: >>> >>> This is a trivial change to allow a 5-digit-or-more year in 'ls' >>> timestamp >>> output. >>> >>> Signed-off-by: Kang-che Sung >> >> >> You realise we're good for almost 8000 more years? :D > > > I guess it can already happen if your clock is grossly miscalibrated, > though? > > Or as a result of corruption in a filesystem, archive, FTP transfer, or > any number of other things (including user error). I guess it's also > conceivable that someone might want to apply `accurate' timestamps > to things like photographs of cave-paintings from the year -5k > > I'd actually be really interested in hearing the motivations for the > change The resulting code is _smaller_. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On Tue, Feb 17, 2015 at 5:52 AM, Rich Felker wrote: > On Mon, Feb 16, 2015 at 11:16:02PM -0500, Joshua Judson Rosen wrote: >> On 02/15/2015 06:06 AM, Steven Honeyman wrote: >> >On 15 February 2015 at 07:38, Explorer wrote: >> >>This is a trivial change to allow a 5-digit-or-more year in 'ls' timestamp >> >>output. >> >> >> >>Signed-off-by: Kang-che Sung >> > >> >You realise we're good for almost 8000 more years? :D >> >> I guess it can already happen if your clock is grossly miscalibrated, though? > > Only on systems with 64-bit time_t. Otherwise years past 2038 don't > exist. :-) BTW: Current kernels internally use 64-bit nanosecond time, and they refuse to set date such that it overflows such counters. I failed to set date to year 2300. 2200 worked. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Changing the primary group
Am 17.02.2015 12:59, schrieb Laszlo Papp: > Hi, > > I am looking for something like usermod -g on desktop. Is it possible > to achieve this feature? I have no idea why you need "usermod -g" (i assume adding a group) i use vi /etc/group > > There are workarounds like adding a group and then removing the > previous, etc, but it is suboptimal. mmmg, changing the primary group is changing the id in the 4th field. see: man 5 passwd hope that helps, wh ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Changing the primary group
On Tue, Feb 17, 2015 at 12:38 PM, walter harms wrote: > > > Am 17.02.2015 12:59, schrieb Laszlo Papp: >> Hi, >> >> I am looking for something like usermod -g on desktop. Is it possible >> to achieve this feature? > > I have no idea why you need "usermod -g" (i assume adding a group) > i use > vi /etc/group 1) If you have no idea, you can read the email subject: Changing the primary group 2) Primary groups ends up /etc/passwd, not /etc/group. Correspondingly, it is the wrong place to look at. >> There are workarounds like adding a group and then removing the >> previous, etc, but it is suboptimal. > > mmmg, changing the primary group is changing the id in the 4th field. > see: man 5 passwd I know, but that is not the point of the question. 1) Editing files manually are bad habit without avoiding race, etc. It is also error-prone. You could say the same for pretty much any passwd and group related issues that you can add a group manually. 2) It is not enough to just look up man 5 passwd. Eventually, you would need to get the group id out of the groupname. I definitely do not want to supply raw group ids. That is mad. :-) Since it was not clear, I will try to clarify: is this feature already available in busybox via one-pass? My suggested workaround is still nicer than editing files manually like that in my opinion, but it is two-pass. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Fwd: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On Tue, Feb 17, 2015 at 8:20 PM, Denys Vlasenko wrote: > > On Tue, Feb 17, 2015 at 5:16 AM, Joshua Judson Rosen > wrote: > > > > I'd actually be really interested in hearing the motivations for the > > change > > The resulting code is _smaller_. Hi everyone, and sorry for late reply. (I'm new in this mailing list.) My original motivation was to avoid that annoying comment saying that "it's buggy after year ", and I believe it should be written right in the first place. Yes, it's smaller also. If fixing the problem would add more than 10 bytes of code, I wouldn't suggest the patch then. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On 17/02/2015 13:52, Explorer wrote: My original motivation was to avoid that annoying comment saying that "it's buggy after year ", and I believe it should be written right in the first place. Would you prefer the following comment: "It's buggy after year 9" ? (Not saying that the patch is a bad idea, but if you want to write it "right", then it's a bit more complex. And totally not worth it.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On Tue, Feb 17, 2015 at 2:29 PM, Laurent Bercot wrote: > On 17/02/2015 13:52, Explorer wrote: >> >> My original motivation was to avoid that annoying comment saying that >> "it's buggy after year ", and I believe it should be written right >> in the first place. > > > Would you prefer the following comment: "It's buggy after year 9" ? Current code is good for any year as long as ctime() returns a result with correct year digits at the end. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Bug in the deluser applet
Hi, 1) busybox addgroup user 2) busybox adduser -G user testuser1 3) busybox adduser -G user testuser2 4) busybox deluser testuser1 5) grep user /etc/passwd /etc/group ... /etc/passwd:testuser2:x:1010:1007:Linux User,,,:/home/testuser2:/bin/bash ... /etc/group:user:x:1007:testuser,testuser2 ^^ ... This is not how the desktop util behaves and I agree with the desktop util in this case. A non-existent user should not remain in /etc/group. Do you agree or disagree? Cheers, L. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in the deluser applet
On Tue, Feb 17, 2015 at 4:52 PM, Laszlo Papp wrote: > Hi, > > 1) busybox addgroup user > 2) busybox adduser -G user testuser1 > 3) busybox adduser -G user testuser2 > 4) busybox deluser testuser1 > 5) grep user /etc/passwd /etc/group > > ... > /etc/passwd:testuser2:x:1010:1007:Linux User,,,:/home/testuser2:/bin/bash > ... > /etc/group:user:x:1007:testuser,testuser2 >^^ Apologies; that is wrong copy/paste. I meant to write this: /etc/group:user:x:1007:testuser1,testuser2 ^^ > ... > > This is not how the desktop util behaves and I agree with the desktop > util in this case. A non-existent user should not remain in > /etc/group. > > Do you agree or disagree? > > Cheers, L. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS
2015-02-17 19:21 GMT+01:00 Xabier Oneca -- xOneca : > Hello Denys, > > 2015-02-15 14:58 GMT+01:00 Denys Vlasenko : >> On Sun, Feb 15, 2015 at 8:03 AM, Explorer wrote: >>> From 60836c395e0d1a71da573175fde410cc69e67b78 Mon Sep 17 00:00:00 2001 >>> From: Explorer09 >>> Date: Sun, 15 Feb 2015 14:50:34 +0800 >>> Subject: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS >>> >>> This adds a 'select' line that if ftpd and ls are both enabled, ls >>> timestamps >>> feature will always be selected. >>> >>> Without this line, FEATURE_LS_TIMESTAMPS will still be enabled internally >>> due >>> to the macro lines like this in ls.c: >>> #if ENABLE_FTPD >>> # undef CONFIG_FEATURE_LS_TIMESTAMPS >>> ... >>> # define CONFIG_FEATURE_LS_TIMESTAMPS 1 >>> ... >>> #endif >>> >>> I would like to have kconfig handle the dependency and letting it explicit >>> to >>> builders. >>> >>> Signed-off-by: Kang-che Sung >> >> I don't think this change is useful. > > You refer to the fact that the config was select'ed, but the code was > not cleaned, don't you? I mean, the patch was not complete. Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS
Hello Denys, 2015-02-15 14:58 GMT+01:00 Denys Vlasenko : > On Sun, Feb 15, 2015 at 8:03 AM, Explorer wrote: >> From 60836c395e0d1a71da573175fde410cc69e67b78 Mon Sep 17 00:00:00 2001 >> From: Explorer09 >> Date: Sun, 15 Feb 2015 14:50:34 +0800 >> Subject: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS >> >> This adds a 'select' line that if ftpd and ls are both enabled, ls >> timestamps >> feature will always be selected. >> >> Without this line, FEATURE_LS_TIMESTAMPS will still be enabled internally >> due >> to the macro lines like this in ls.c: >> #if ENABLE_FTPD >> # undef CONFIG_FEATURE_LS_TIMESTAMPS >> ... >> # define CONFIG_FEATURE_LS_TIMESTAMPS 1 >> ... >> #endif >> >> I would like to have kconfig handle the dependency and letting it explicit >> to >> builders. >> >> Signed-off-by: Kang-che Sung > > I don't think this change is useful. You refer to the fact that the config was select'ed, but the code was not cleaned, don't you? Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in the deluser applet
WARNING: this is pseudo code. Do not use it as is. It makes my
/etc/group empty after the run, but it ought to show the concept I am
thinking of. As indicated, the implementation has some bug currently.
Any feedback is welcome.
commit d7075bb9195a65d11b43f516112f5b0134cbc62a
Author: Laszlo Papp
Date: Tue Feb 17 20:01:04 2015 +
Delete the user from all the groups for user deletion
diff --git a/libbb/update_passwd.c b/libbb/update_passwd.c
index a30af6f..f280813 100644
--- a/libbb/update_passwd.c
+++ b/libbb/update_passwd.c
@@ -62,6 +62,8 @@ static void check_selinux_update_passwd(const char *username)
only if CONFIG_PASSWD=y and applet_name[0] == 'p' like in passwd
or if CONFIG_CHPASSWD=y and applet_name[0] == 'c' like in chpasswd
+ 8) delete a user from all groups : update_passwd(FILE, NULL, NULL, MEMBER)
+
This function does not validate the arguments fed to it
so the calling program should take care of that.
@@ -81,7 +83,7 @@ int FAST_FUNC update_passwd(const char *filename,
FILE *new_fp;
char *fnamesfx;
char *sfx_char;
- char *name_colon;
+ char *name_colon = 0;
unsigned user_len;
int old_fd;
int new_fd;
@@ -99,13 +101,15 @@ int FAST_FUNC update_passwd(const char *filename,
if (filename == NULL)
return ret;
- check_selinux_update_passwd(name);
+ if (name) check_selinux_update_passwd(name);
/* New passwd file, "/etc/passwd+" for now */
fnamesfx = xasprintf("%s+", filename);
sfx_char = &fnamesfx[strlen(fnamesfx)-1];
- name_colon = xasprintf("%s:", name);
- user_len = strlen(name_colon);
+if (name) {
+name_colon = xasprintf("%s:", name);
+user_len = strlen(name_colon);
+}
if (shadow)
old_fp = fopen(filename, "r+");
@@ -167,7 +171,7 @@ int FAST_FUNC update_passwd(const char *filename,
line = xmalloc_fgetline(old_fp);
if (!line) /* EOF/error */
break;
- if (strncmp(name_colon, line, user_len) != 0) {
+ if (name && strncmp(name_colon, line, user_len) != 0) {
fprintf(new_fp, "%s\n", line);
goto next;
}
@@ -175,8 +179,21 @@ int FAST_FUNC update_passwd(const char *filename,
/* We have a match with "name:"... */
cp = line + user_len; /* move past name: */
+if (!name && member) {
+struct group* g;
+while ((g = getgrent())) {
+char **s= g->gr_mem;
+char **d = s;
+while (s && *s) {
+if (strcmp(*s, member)) { *d = *s; ++d; }
+++s;
+}
+*d = 0;
+}
+}
+
#if ENABLE_FEATURE_ADDUSER_TO_GROUP || ENABLE_FEATURE_DEL_USER_FROM_GROUP
- if (member) {
+if (name && member) {
/* It's actually /etc/group+, not /etc/passwd+ */
if (ENABLE_FEATURE_ADDUSER_TO_GROUP
&& applet_name[0] == 'a'
diff --git a/loginutils/deluser.c b/loginutils/deluser.c
index 01a9386..8219569 100644
--- a/loginutils/deluser.c
+++ b/loginutils/deluser.c
@@ -82,6 +82,9 @@ int deluser_main(int argc, char **argv)
do_delgroup:
/* "delgroup GROUP" or "delgroup USER GROUP" */
if (do_deluser < 0) { /* delgroup after deluser? */
+ pfile = bb_path_group_file;
+if (update_passwd(pfile, NULL, NULL, name) == -1)
+return EXIT_FAILURE;
gr = getgrnam(name);
if (!gr)
return EXIT_SUCCESS;
@@ -99,7 +102,6 @@ int deluser_main(int argc, char **argv)
}
//endpwent();
}
- pfile = bb_path_group_file;
if (ENABLE_FEATURE_SHADOWPASSWDS)
sfile = bb_path_gshadow_file;
}
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS
On Tue, Feb 17, 2015 at 7:21 PM, Xabier Oneca -- xOneca wrote: > 2015-02-15 14:58 GMT+01:00 Denys Vlasenko : >> On Sun, Feb 15, 2015 at 8:03 AM, Explorer wrote: >>> From 60836c395e0d1a71da573175fde410cc69e67b78 Mon Sep 17 00:00:00 2001 >>> From: Explorer09 >>> Date: Sun, 15 Feb 2015 14:50:34 +0800 >>> Subject: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS >>> >>> This adds a 'select' line that if ftpd and ls are both enabled, ls >>> timestamps >>> feature will always be selected. >>> >>> Without this line, FEATURE_LS_TIMESTAMPS will still be enabled internally >>> due >>> to the macro lines like this in ls.c: >>> #if ENABLE_FTPD >>> # undef CONFIG_FEATURE_LS_TIMESTAMPS >>> ... >>> # define CONFIG_FEATURE_LS_TIMESTAMPS 1 >>> ... >>> #endif >>> >>> I would like to have kconfig handle the dependency and letting it explicit >>> to >>> builders. >>> >>> Signed-off-by: Kang-che Sung >> >> I don't think this change is useful. > > You refer to the fact that the config was select'ed, but the code was > not cleaned, don't you? I don't see how is this change useful. I can see why it can be _harmful_. Imagine that ftpd.c is changed so that it no longer requires FEATURE_LS_TIMESTAMPS. There are high changes that the "select" statement will not be removed (since it is not in that file, and it's not obvious that it is related to it), and as such will become erroneous. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH, RFC] wget is appending instead of replacing with "--header"
Hi,
https://bugs.debian.org/744725
wget is appending instead of replacing with "--header"
To quote current big wget docs
http://www.gnu.org/software/wget/manual/html_node/HTTP-Options.html
‘--header=header-line’
Send header-line along with the rest of the headers in each HTTP request. The
supplied header is sent as-is, which means it must contain name and value
separated by colon, and must not contain newlines.
You may define more than one additional header by specifying ‘--header’ more
than once.
wget --header='Accept-Charset: iso-8859-2' \
--header='Accept-Language: hr'\
http://fly.srk.fer.hr/
Specification of an empty string as the header value will clear all previous
user-defined headers.
As of Wget 1.10, this option can be used to override headers otherwise
generated automatically. This example instructs Wget to connect to localhost,
but to specify ‘foo.bar’ in the Host header:
wget --header="Host: foo.bar" http://localhost/
In versions of Wget prior to 1.10 such use of ‘--header’ caused sending of
duplicate headers.
I'm attaching 2 variants to implement the "override headers" part that was
introduced in the big wget in 1.10. As i'm just now seeing that "clear all
previous user headers" so that part is not implemented and i'm not sure how
useful it is in practise (i would not blindly add it).
Neither variant make me particularly happy and i'm not sure how to phrase
it better right now.
Better ideas?
Denys, is one of this variants good enough to apply as is for now?
TIA and cheers,
Bernhard
function old new delta
wget_main 29673108+141
.rodata 155809 155872 +63
wget_user_headers - 62 +62
retrieve_file_data 435 456 +21
progress_meter 120 126 +6
--
(add/remove: 1/0 grow/shrink: 4/0 up/down: 293/0) Total: 293 bytes
text databssdechexfilename
822042 4123 9552 835717 cc085busybox_old
822273 4123 9552 835948 cc16cbusybox_unstripped
diff --git a/networking/wget.c b/networking/wget.c
index 1013f66..3cfe706 100644
--- a/networking/wget.c
+++ b/networking/wget.c
@@ -55,6 +55,33 @@ static const char P_FTP[] = "ftp";
static const char P_HTTP[] = "http";
static const char P_HTTPS[] = "https";
+#if ENABLE_FEATURE_WGET_LONG_OPTIONS
+/* User-specified headers prevent using our corresponding built-in headers. */
+enum {
+ HDR_HOST = (1<<0),
+ HDR_USER_AGENT = (1<<1),
+ HDR_RANGE = (1<<2),
+ HDR_AUTHORIZATION = (1<<3) * ENABLE_FEATURE_WGET_AUTHENTICATION,
+ HDR_PROXY_AUTHORIZATION = (1<<4) * ENABLE_FEATURE_WGET_AUTHENTICATION,
+};
+static const char wget_user_headers[] ALIGN1 =
+ "Host:\0User-Agent:\0Range:\0"
+# if ENABLE_FEATURE_WGET_AUTHENTICATION
+ "Authorization:\0Proxy-Authorization:\0"
+# endif
+ ;
+# define USR_HEADER_HOST (G.user_headers & HDR_HOST)
+# define USR_HEADER_USER_AGENT (G.user_headers & HDR_USER_AGENT)
+# define USR_HEADER_RANGE (G.user_headers & HDR_RANGE)
+# define USR_HEADER_AUTHORIZATION (G.user_headers & HDR_AUTHORIZATION)
+# define USR_HEADER_PROXY_AUTHORIZATION (G.user_headers & HDR_PROXY_AUTHORIZATION)
+#else /* No long options, no user-headers :( */
+# define USR_HEADER_HOST 0
+# define USR_HEADER_USER_AGENT 0
+# define USR_HEADER_RANGE 0
+# define USR_HEADER_AUTHORIZATION 0
+# define USR_HEADER_PROXY_AUTHORIZATION 0
+#endif
/* Globals */
struct globals {
@@ -69,6 +96,7 @@ struct globals {
#if ENABLE_FEATURE_WGET_LONG_OPTIONS
char *post_data;
char *extra_headers;
+ unsigned char user_headers; /* Headers mentioned by the user */
#endif
char *fname_out;/* where to direct output (-O) */
const char *proxy_flag; /* Use proxies if env vars are set */
@@ -722,6 +750,9 @@ static void NOINLINE retrieve_file_data(FILE *dfp)
progress_meter(PROGRESS_END);
}
+#define httpcmd(fp, fmt, ...) \
+ { log_io("> " fmt, ##__VA_ARGS__); fprintf(fp, fmt, ##__VA_ARGS__); }
+
static void download_one_url(const char *url)
{
bool use_proxy; /* Use proxies if env vars are set */
@@ -830,43 +861,46 @@ static void download_one_url(const char *url)
#endif
/* Send HTTP request */
if (use_proxy) {
- fprintf(sfp, "GET %s://%s/%s HTTP/1.1\r\n",
+ httpcmd(sfp, "GET %s://%s/%s HTTP/1.1\r\n",
target.protocol, target.host,
target.path);
} else {
- fprintf(sfp, "%s /%s HTTP/1.1\r\n",
+ httpcmd(sfp, "%s /%s HTTP/1.1\r\n",
(option_mask32 & WGET_OPT_POST_DATA) ? "POST" : "GET",
target.path);
}
-
- fprintf(sfp, "Host: %s\r\nUser-Agent: %s\r\n",
- target.host, G.user_agent);
+ if (!USR_HEADER_HOST)
+ httpcmd(sfp, "Host: %s\r\n", target.host);
+ if (!USR_HEADER_USER_AGENT)
+ httpcmd(sfp, "User-Agent: %s\r
Re: [PATCH] dc: tweak parsing
On Mon, Feb 16, 2015 at 09:33:46PM +0100, Bernhard Reutner-Fischer wrote: > On February 16, 2015 5:13:31 PM GMT+01:00, Denys Vlasenko > wrote: > >Applied, thanks! > > That's even better. > Thanks a lot! Can you please schedule this for the next stable point release? TIA, ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On Tue, Feb 17, 2015 at 02:29:05PM +0100, Laurent Bercot wrote: > On 17/02/2015 13:52, Explorer wrote: > >My original motivation was to avoid that annoying comment saying that > >"it's buggy after year ", and I believe it should be written right > >in the first place. > > Would you prefer the following comment: "It's buggy after year 9" ? > > (Not saying that the patch is a bad idea, but if you want to write > it "right", then it's a bit more complex. And totally not worth it.) Read the new code again. It works fine for that case as far as I can tell. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] CONFIG_FTPD should select FEATURE_LS_TIMESTAMPS
2015-02-17 21:47 GMT+01:00 Denys Vlasenko : > On Tue, Feb 17, 2015 at 7:21 PM, Xabier Oneca -- xOneca > wrote: >> 2015-02-15 14:58 GMT+01:00 Denys Vlasenko : >>> >>> I don't think this change is useful. >> >> You refer to the fact that the config was select'ed, but the code was >> not cleaned, don't you? > > I don't see how is this change useful. > > I can see why it can be _harmful_. > > Imagine that ftpd.c is changed so that it no longer requires > FEATURE_LS_TIMESTAMPS. There are high changes that the "select" > statement will not be removed (since it is not in that file, > and it's not obvious that it is related to it), > and as such will become erroneous. The code is about a feature of FTPD. Now, the code is in LS file. The proposed change moves that config dependency to the Config.src file, where it belongs. Well, it could/should even be moved to ftpd.c, in a //config: comment. I am not saying you should approve sent patch (I wouldn't), but It makes sense the change OP proposed. Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On 17/02/2015 22:37, Rich Felker wrote: Read the new code again. It works fine for that case as far as I can tell. Indeed, my apologies (and I realized that after Denys' message). I always get confused by printf conversion specifications as soon as there's anything more than a single conversion specifier character. Bleh format strings. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ls: no longer assume a 4-digit year on file timestamp.
On 2015-02-17 07:24, Denys Vlasenko wrote: On Tue, Feb 17, 2015 at 5:52 AM, Rich Felker wrote: On Mon, Feb 16, 2015 at 11:16:02PM -0500, Joshua Judson Rosen wrote: On 02/15/2015 06:06 AM, Steven Honeyman wrote: On 15 February 2015 at 07:38, Explorer wrote: This is a trivial change to allow a 5-digit-or-more year in 'ls' timestamp output. Signed-off-by: Kang-che Sung You realise we're good for almost 8000 more years? :D I guess it can already happen if your clock is grossly miscalibrated, though? Only on systems with 64-bit time_t. Otherwise years past 2038 don't exist. :-) BTW: Current kernels internally use 64-bit nanosecond time, and they refuse to set date such that it overflows such counters. I failed to set date to year 2300. 2200 worked. OTOH, I tried setting file-timestamps in the distant future and past with (coreutils) "touch" command, and that worked just fine: jrosen@bz:~$ touch --date='+8000 years' tstamp; ls --full tstamp -rw-r--r-- 1 jrosen jrosen 0 10015-02-17 18:21:45.371567679 -0500 tstamp jrosen@bz:~$ touch --date='-8000 years' tstamp; ls --full tstamp -rw-r--r-- 1 jrosen jrosen 0 -5985-02-17 18:21:09.776568641 -0456 tstamp I guess that leaves "user error" as a viable path -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr." ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in the deluser applet
On Tuesday 17 February 2015 17:52:06 Laszlo Papp wrote: > Hi, > > 1) busybox addgroup user > 2) busybox adduser -G user testuser1 > 3) busybox adduser -G user testuser2 > 4) busybox deluser testuser1 > 5) grep user /etc/passwd /etc/group > > ... > /etc/passwd:testuser2:x:1010:1007:Linux User,,,:/home/testuser2:/bin/bash > ... > /etc/group:user:x:1007:testuser,testuser2 >^^ > ... > > This is not how the desktop util behaves and I agree with the desktop > util in this case. A non-existent user should not remain in > /etc/group. > > Do you agree or disagree? > > Cheers, L. Hi, i agree that this case is not covered by actual bb's deluser code. What we cover at the moment is: deluser USER (and group with same name if empty) deluser USER from GROUP The desktop util behaviour could be added tough. By looking at the pseudo code you posted in a later mail I wonder if it could be easier to change deluser rather than update_passwd which is more complex. Like: do_deluser get_user_group_list do_delgroup of primary group while_list do_deluser_from_group or do_deluser while getgrent do_deluser_from_group(user, grname) do_delgroup of primary group Ciao, Tito ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
Hi all,
I ended up using rdate on this particular case but I think it would be
nice if ntpd could be used as described.
I don't have enough knowledge about the protocol to know what are the
implications of not waiting for the burst mode to end for option -q
(as per Miroslav's patch). Can anyone shed some light?
Thank you,
Guillermo
2015-01-29 13:47 GMT+01:00 Miroslav Lichvar :
> On Tue, Jan 27, 2015 at 07:27:18PM +0100, Guillermo Rodriguez Garcia wrote:
>> Is there a way to make ntpd work just like ntpdate (just use the first
>> response received to set the time)? This is to set the approximate
>> time at boot as quickly as possible before starting other time sensitive
>> services.
>
> By default, ntpdate actually makes 4 measurements before it sets the
> clock, but older versions didn't wait between queries so it appeared
> like there was only one. With current versions, which use 2s polling
> interval, it takes at least 6 seconds.
>
>> The closest I can get is ntpd -nqp but this seems to need
>> 5 valid samples in order to set the time.
>
> It seems it waits for the burst mode to end before it tries to select
> a source. I'm not sure that is necessary.
>
> --- a/networking/ntpd.c
> +++ b/networking/ntpd.c
> @@ -1084,7 +1084,7 @@ select_and_cluster(void)
>
> num_points = 0;
> item = G.ntp_peers;
> - if (G.initial_poll_complete) while (item != NULL) {
> + while (item != NULL) {
> double rd, offset;
>
> p = (peer_t *) item->data;
>
>
> With this change ntpd -q will set the clock with just two samples,
> that's about 1-2 seconds total time.
>
> --
> Miroslav Lichvar
--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in the deluser applet
I thought about this, too, when writing the patch, but I rejected it because it is not simpler, in fact more complex, it is also not the right layer for the change. In addition, it would also be somewhat slower to execute. On Wednesday, February 18, 2015, tito wrote: > On Tuesday 17 February 2015 17:52:06 Laszlo Papp wrote: > >> Hi, > >> > >> 1) busybox addgroup user > >> 2) busybox adduser -G user testuser1 > >> 3) busybox adduser -G user testuser2 > >> 4) busybox deluser testuser1 > >> 5) grep user /etc/passwd /etc/group > >> > >> ... > >> /etc/passwd:testuser2:x:1010:1007:Linux User,,,:/home/testuser2:/bin/bash > >> ... > >> /etc/group:user:x:1007:testuser,testuser2 > >> ^^ > >> ... > >> > >> This is not how the desktop util behaves and I agree with the desktop > >> util in this case. A non-existent user should not remain in > >> /etc/group. > >> > >> Do you agree or disagree? > >> > >> Cheers, L. > > > > Hi, > > i agree that this case is not covered by actual bb's deluser code. > > What we cover at the moment is: > > > > deluser USER (and group with same name if empty) > > deluser USER from GROUP > > > > > > The desktop util behaviour could be added tough. > > By looking at the pseudo code you posted in a later > > mail I wonder if it could be easier to change > > deluser rather than update_passwd which is more complex. > > Like: > > > > do_deluser > > get_user_group_list > > do_delgroup of primary group > > while_list > > do_deluser_from_group > > or > > do_deluser > > while getgrent > > do_deluser_from_group(user, grname) > > do_delgroup of primary group > > > > Ciao, > > Tito ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in the deluser applet
On February 18, 2015 8:34:14 AM GMT+01:00, Laszlo Papp wrote: >I thought about this, too, when writing the patch, but I rejected it >because it is not simpler, in fact more complex, it is also not the >right >layer for the change. In addition, it would also be somewhat slower to >execute. > >On Wednesday, February 18, 2015, tito wrote: >> On Tuesday 17 February 2015 17:52:06 Laszlo Papp wrote: >> >>> Hi, >> >>> >> >>> 1) busybox addgroup user >> >>> 2) busybox adduser -G user testuser1 >> >>> 3) busybox adduser -G user testuser2 >> >>> 4) busybox deluser testuser1 >> >>> 5) grep user /etc/passwd /etc/group >> >>> >> >>> ... >> >>> /etc/passwd:testuser2:x:1010:1007:Linux >User,,,:/home/testuser2:/bin/bash >> >>> ... >> >>> /etc/group:user:x:1007:testuser,testuser2 >> >>> ^^ >> >>> ... >> >>> >> >>> This is not how the desktop util behaves and I agree with the >desktop >> >>> util in this case. A non-existent user should not remain in >> >>> /etc/group. >> >>> >> >>> Do you agree or disagree? >> >>> >> >>> Cheers, L. >> >> >> >> Hi, >> >> i agree that this case is not covered by actual bb's deluser code. >> >> What we cover at the moment is: >> >> >> >> deluser USER (and group with same name if empty) >> >> deluser USER from GROUP >> >> >> >> >> >> The desktop util behaviour could be added tough. >> >> By looking at the pseudo code you posted in a later >> >> mail I wonder if it could be easier to change >> >> deluser rather than update_passwd which is more complex. >> >> Like: >> >> >> >> do_deluser >> >> get_user_group_list >> >> do_delgroup of primary group >> >> while_list >> >> do_deluser_from_group >> >> or >> >> do_deluser >> >> while getgrent >> >> do_deluser_from_group(user, grname) >> >> do_delgroup of primary group I'd do the latter I think. Tito, can you please cook a patch? TIA! ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
