Re: [DNG] Systemd Shims
GUI frontend is ready. Now, it is time for users to discover deep bugs that only show their heads when the user number increases. A popup window has been provided to display detailed information about any available wifi hotspots. This simplified the design and implementation of the GUI. Hopefully, users find it useful. On 21/08/2015, Edward Bartolo edb...@gmail.com wrote: I think, I can also upload the Lazarus code of the frontend. I am using the application, and for those who love the principle of Keep it simple stuptid, it is a nice simple application which is run on request. It is also controlled by the user, instead of automatically making decisions behind the scenes. Automation will definitely take more time to do, but for the KISS lovers, the application can be provided as is, with a version number of 0.1 or something similar. When the C backend is hardened enough, it will be time for upload to git.devuan.org. Cheers, and may DEVUAN be enjoyed by anyone wanting software freedom. Edward On 21/08/2015, Edward Bartolo edb...@gmail.com wrote: At long last, the backend runs without the frontend having for it to finish as I wished. This got rid of frontend hangs. On 21/08/2015, Steve Litt sl...@troubleshooters.com wrote: On Fri, 21 Aug 2015 06:47:13 +0100 Edward Bartolo edb...@gmail.com wrote: Parsing headaches: I have this chunk of data retrieved from the backend which I need to parse *reliably*. The goal is to read the SSID and the corresponsing signal strength. How should I proceed. This part of code will be done from within Lazarus. Please, be informed that Lazarus generated GUI uses GTK* as a base. The executable can is also statically built which means an increased portability. Executables are about 3 MB. In the past I have written such applications that dwarf what I am doing and still the size is small. Here is what I want to parse: root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID Channel:1 Frequency:2.412 GHz (Channel 1) Quality=70/70 Signal level=-34 dBm Encryption key:on ESSID:EB-TP-LNK67 -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=24/70 Signal level=-86 dBm Encryption key:on ESSID:TNCAPA0332D -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=30/70 Signal level=-80 dBm Encryption key:on ESSID:Home WiFi :-) Hi Edward, At this point you're a lot more knowledgeable on this situation than I, but I'll give you an opinion. If this problem were any more complex, I'd suggest spawning awk, but it looks to me like as long as you can get these lines into Lazarus, I think you're golden. Please refer to http://dpaste.com/0FZE769 ... First thing: By using grep -B, you're throwing away some information you need: Specifically, encryption type. I'd recommend you pull *all* the output from iwscan $device scanning into a Turbo Pascal (you know what I mean) file linked into your Lazarus program, except ^\s+IE: Unknown. It's pretty easy to parse: * Throw away anything beginning with ^\s*IE: Unknown * Throw away ^$device\s+Scan completed * Every ^\s*Cell \d starts a new record, record the cell number Every line is one of the following: 1. ^$device\s+Scan Completed 2. ^\s+Cell 3. ^\s+IE: Unknown 4. ^\s+\S.*: 5. ^\s+\S.*= 6. Everything else #3 can be avoided by having your original command be the following: root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -v ^\s+IE: Unknown: #4 are the key/value pairs comprising most of what you need #6 are all additional information appended to the #4 item preceding them. So you need a somewhat stateful algorithm. You may or may not need a Group Cipher, Pairwise Ciphers, and/or Authentication Suites. If you don't need those three things, I think you can throw away all #6. #2 separates records #5 is the signal quality/level line. Give it its own subroutine. #1 gets thrown out Anyway, you definitely need to capture the encryption type, and by using your grep -B4 ESSID you're throwing that away. NetworkManager and Wicd both show encryption type on the ESSID list, and when I use either of this, I want to know which ones are WPA as opposed to (eeeuuu) WEP and which are (be very careful) unencrypted. HTH, Steve Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes: I reorganised the C source code into header files and C code files. I also tested the backend to make sure the reorganisation of the code did not impact its functionality. I also included several 'patches' as suggested and made sure strcat does behave properly. Needless to state the obvious this code is still in development which means it is not yet ready to be used. However, for development evaluation purposes it works. Here is my humble C code. An additional remark: Whenever publishing code which does something useful, one will encounter two kinds of 'stock' reprimands 1) You shouldn't be doing this at all, instead ... (on to a long discussion of hypothetical approaches) 2) You're code sucks because you're not using MY favorite, freely downloadable library ... (C++ considered a freely downloadable library for this purpose) 1) is best ignored as it basically just prevents things from getting done. Provided the existing code works, 2) is best ignored, too. Everything could be done in a different and better way and improving something which exists is a lot easier than creating it from scratch. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Rainer Weikusat rainerweiku...@virginmedia.com writes: [...] #include stdlib.h #include stdio.h There's an #include unistd.h missing here in order to make the code compile w/o warnings. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes:
I reorganised the C source code into header files and C code files. I
also tested the backend to make sure the reorganisation of the code
did not impact its functionality. I also included several 'patches' as
suggested and made sure strcat does behave properly.
Needless to state the obvious this code is still in development which
means it is not yet ready to be used. However, for development
evaluation purposes it works.
Here is my humble C code.
There's one thing in there I consider very problematic:
int exec(const char* cmd, char* out)
{
const int buf_size = 128;
FILE * pipe = popen(cmd, r);
char buffer[buf_size];
while(!feof(pipe)) {
if(fgets(buffer, buf_size, pipe) != NULL)
{
if (out != NULL)
strcat(out, buffer);
else strcpy(out, buffer);
}
}
return pclose(pipe);
}
This blindly copies an indefinite amount of data into a caller provided
buffer but the caller cannot possibly know how large the buffer has to
be. Two actual problems related to that:
int connectionConnect(char* essid) //argv[2]
{
char* s = 0;
char command[1024];
int result = snprintf(command, 1024, /sbin/ifup wlan0 -i
IFACES_PATH/%s, essid);
if (result = 1024)
return 105;
printf(command);
int q = exec(command, s);
printf(s);
return q;
}
int disconnectActiveConnection()
{
char* s = 0;
char command[1024];
strcpy(command, /sbin/ifdown wlan0);
int q = exec(command, s);
printf(s);
return q;
}
This runs exec with null pointer as second argument. In case there is
actually any output, the exec function will try to copy the data to
that and this should end up terminating the program with a SIGSEGV.
IMHO, the exec function should return the output written by the command
in a dynamically allocated buffer. And 'exec' is an unfortunate name as
it closely resembles the execve system call (and 'exec' is commonly used
to request such an operation, eg, by the shell). Some code implementing
the suggestion.
NB: I've tested that the buffer management works. The function will
return a NULL pointer to indicate that some kind of 'system error'
occured. Success-but-no-output returns an empty string. The caller must
free the returned string if memory leaks are to be avoided. The command
exit status is ignored. This may be a worthwhile avenue for future
extensions.
NB^2: This is also a nice demonstration that stdio isn't always the
easiest way to handle I/O.
#include stdlib.h
#include stdio.h
#define BUF_SIZE1024
char *read_command(const char *cmd)
{
FILE *fp;
char *output, *p, *e, *tmp;
ssize_t nr;
int fd;
fp = popen(cmd, r);
if (!fp) {
perror(popen);
return NULL;
}
output = malloc(BUF_SIZE);
if (!output) {
perror(malloc);
return NULL;
}
fd = fileno(fp);
p = output;
e = output + BUF_SIZE;
while ((nr = read(fd, p, e - p)) 0) {
p += nr;
if (p == e) {
nr = (p - output) * 2;
tmp = realloc(output, nr);
if (!tmp) {
perror(realloc);
goto err;
}
e = tmp + nr;
p = tmp + (p - output);
output = tmp;
}
}
if (nr 0) {
perror(read);
goto err;
}
pclose(fp);
*p = 0;
return output;
err:
pclose(fp);
free(output);
return NULL;
}
int main(int argc, char **argv)
{
char *output;
output = read_command(argv[1]);
fputs(output, stdout);
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, Aug 21, 2015 at 12:51:55PM +0100, Rainer Weikusat wrote: That's going to work with this particular problem which you incorrectly (the original path wasn't a macro) reduced to appending a string of unknown length to a constant string. Taking this into account, a solution without snprintf would become something like #define PATH /tmp/ char *p; p = alloca(sizeof(PATH) + strlen(argv[1])); Should that be p = alloca(sizeof(PATH) + strlen(argv[1]) + 1); sprintf(p, %s%s, PATH, argv[1]); so there's space for the terminating '\0'? or am I missing something obvious (as I did last time I tried fixing some posted code? or putting this into other terms: The snprintf buys you exactly nothing. And you could have used asprintf to begin with. This would even address what was considered to be the issue, namely, that memory management and memory use are separate functions and that the correctness of the latter depends on the correctness of the former via implicit semantic constraints a compiler cannot check, something the snprintf-code exhibits as well as it is still composed of the three steps 1. Calculate the required length based on the input data. 2. Allocate a buffer of a sufficient size. 3. Copy the input data into this buffer. Just in a somewhat less obvious way. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
I think, I can also upload the Lazarus code of the frontend. I am using the application, and for those who love the principle of Keep it simple stuptid, it is a nice simple application which is run on request. It is also controlled by the user, instead of automatically making decisions behind the scenes. Automation will definitely take more time to do, but for the KISS lovers, the application can be provided as is, with a version number of 0.1 or something similar. When the C backend is hardened enough, it will be time for upload to git.devuan.org. Cheers, and may DEVUAN be enjoyed by anyone wanting software freedom. Edward On 21/08/2015, Edward Bartolo edb...@gmail.com wrote: At long last, the backend runs without the frontend having for it to finish as I wished. This got rid of frontend hangs. On 21/08/2015, Steve Litt sl...@troubleshooters.com wrote: On Fri, 21 Aug 2015 06:47:13 +0100 Edward Bartolo edb...@gmail.com wrote: Parsing headaches: I have this chunk of data retrieved from the backend which I need to parse *reliably*. The goal is to read the SSID and the corresponsing signal strength. How should I proceed. This part of code will be done from within Lazarus. Please, be informed that Lazarus generated GUI uses GTK* as a base. The executable can is also statically built which means an increased portability. Executables are about 3 MB. In the past I have written such applications that dwarf what I am doing and still the size is small. Here is what I want to parse: root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID Channel:1 Frequency:2.412 GHz (Channel 1) Quality=70/70 Signal level=-34 dBm Encryption key:on ESSID:EB-TP-LNK67 -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=24/70 Signal level=-86 dBm Encryption key:on ESSID:TNCAPA0332D -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=30/70 Signal level=-80 dBm Encryption key:on ESSID:Home WiFi :-) Hi Edward, At this point you're a lot more knowledgeable on this situation than I, but I'll give you an opinion. If this problem were any more complex, I'd suggest spawning awk, but it looks to me like as long as you can get these lines into Lazarus, I think you're golden. Please refer to http://dpaste.com/0FZE769 ... First thing: By using grep -B, you're throwing away some information you need: Specifically, encryption type. I'd recommend you pull *all* the output from iwscan $device scanning into a Turbo Pascal (you know what I mean) file linked into your Lazarus program, except ^\s+IE: Unknown. It's pretty easy to parse: * Throw away anything beginning with ^\s*IE: Unknown * Throw away ^$device\s+Scan completed * Every ^\s*Cell \d starts a new record, record the cell number Every line is one of the following: 1. ^$device\s+Scan Completed 2. ^\s+Cell 3. ^\s+IE: Unknown 4. ^\s+\S.*: 5. ^\s+\S.*= 6. Everything else #3 can be avoided by having your original command be the following: root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -v ^\s+IE: Unknown: #4 are the key/value pairs comprising most of what you need #6 are all additional information appended to the #4 item preceding them. So you need a somewhat stateful algorithm. You may or may not need a Group Cipher, Pairwise Ciphers, and/or Authentication Suites. If you don't need those three things, I think you can throw away all #6. #2 separates records #5 is the signal quality/level line. Give it its own subroutine. #1 gets thrown out Anyway, you definitely need to capture the encryption type, and by using your grep -B4 ESSID you're throwing that away. NetworkManager and Wicd both show encryption type on the ESSID list, and when I use either of this, I want to know which ones are WPA as opposed to (eeeuuu) WEP and which are (be very careful) unencrypted. HTH, Steve Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Isaac Dunham ibid...@gmail.com writes:
On Wed, Aug 19, 2015 at 08:30:44PM +, Roger Leigh wrote:
On 19/08/2015 17:39, Rainer Weikusat wrote:
#define IFACE_TMPL \
auto lo\n \
iface lo inet loopback\n\n \
iface wlan0 inet dhcp\n \
wpa-ssid %s\n \
wpa-psk \%s\\n
#define IFACES_PATH /tmp
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
I'm not picking on this post in particular out of the rest of today's
thread, but I did think this was a good example. While I don't want to act
like a rabid C++ zealot, stuff like this really makes me shudder due to the
fragility and unnecessary complexity for something which is really trivial.
While the relative safety and security of C string handling can be debated,
I do think the question needs asking: Why not use a language with proper
safe string handling and avoid the issue entirely? It's only safe until
it's refactored to break the existing assumptions and make it accidentally
unsafe. The constants such as 2, 1 plus the strlen() calls are prime
candidates for future bugs. It's not like this /needs/ to be done in C.
It's not like it needs to be done this way in C, either. ;-)
C provides snprintf, which looks like printf to a memory buffer but
returns the number of bytes that it would output if there were enough space.
You could thus do:
// same includes and defines
int main (int argc, char **argv)
{
FILE *fp;
char *path;
ssize_t bytes;
if (argc 3) {
printf( usage: %s ESSID PASSWORD\n
writes an interfaces stanza to
IFACES_PATH /ESSID\n, argv[0]);
exit(64);
}
bytes = snprintf(NULL, 0, IFACES_PATH /%s, argv[1]);
path = malloc(bytes);
if (!path) {
perror(argv[0]);
exit(71);
}
// enough memory is guaranteed
snprintf(path, bytes, IFACES_PATH /%s, argv[1]);
That's going to work with this particular problem which you incorrectly
(the original path wasn't a macro) reduced to appending a string of
unknown length to a constant string. Taking this into account, a
solution without snprintf would become something like
#define PATH /tmp/
char *p;
p = alloca(sizeof(PATH) + strlen(argv[1]));
sprintf(p, %s%s, PATH, argv[1]);
or putting this into other terms: The snprintf buys you exactly
nothing. And you could have used asprintf to begin with. This would even
address what was considered to be the issue, namely, that memory
management and memory use are separate functions and that the
correctness of the latter depends on the correctness of the former via
implicit semantic constraints a compiler cannot check, something the
snprintf-code exhibits as well as it is still composed of the three
steps
1. Calculate the required length based on the input data.
2. Allocate a buffer of a sufficient size.
3. Copy the input data into this buffer.
Just in a somewhat less obvious way.
Considering code I have had the mispleasure to deal with, I consider the
double snprintf a disaster waiting to happen. Sooner or later, some
copy'n'paste rough rider will change the second call to
snprintf(path, bytes, IFACES_PATH /%/%.%, argv[1], argv[2], argv[3]):
or even
// snprintf doesn't work
sprintf(path, IFACES_PATH /%/%.%, argv[1], argv[2], argv[3]);
(as 'quick bug fix' of the first change) and likely won't even look at
the other code.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
As it is, the frontend can connect on user request. The user can run
the frontend application, click connect and terminate the application
and the connection will continue to be functional. This is real KISS
in practice but I can also make the application automatically run on
startup of the OS.
Then the frontend can automatically attempt a connection prompting
the user if no connections are set up.
In the first case, I can hide the application window altogether only
showing it on failing to connect.
What do you suggest?
-
On 19/08/2015, marc marc...@welz.org.za wrote:
Hello
Now, I should think, the buffer overruns should not be possible, but I
am open to criticism. Buffer overruns are not something to be proud of
and correction when taken appropriately is a blessing.
Now, I will sleep as I am totally exhausted from coding all day long.
Well, you deserved a good rest - congratulations for making the
effort to learn something and contributing software. Doing something
almost always beats talking about it.
Here is some feedback from me - for tomorrow, use or don't use.
* The main() function is special, returning negative values
in it doesn't have the expected results - generally values
between 0 and 255 are possible. Convention is 0 is success,
1 some sort of alternative success and larger numbers a
failure. /usr/include/sysexits.h defines some common failure
modes, though not that many applications use those codes.
Anyway - try for yourself: run a program which returns a negative
value and then use echo $? after it completes to see what
actually made it back
* In your deletion logic you use
int deleteConnect(char* essid) //argv[2]
{
//char* s = 0;
char command[1024];
strcpy(command, /bin/rm /etc/network/wifi/);
strcat(command, essid);
int q = exec(command, 0);
//printf(s);
return q;
}
So it turns out there is a system call which is used internally
by rm to do the deletion. It is called unlink (man 2 unlink)
Using it means you could do
int deleteConnect(char* essid) //argv[2]
{
char command[SIZE];
int result;
result = snprintf(command, SIZE, /etc/network/wifi/%s,
essid)
if(result = SIZE){
return -1;
}
return unlink(command);
}
Code size-wise it doesn't look that different, but instead of
creating a shell process which then launches a rm process which
then does the unlink, you can do the unlink yourself - which
is faster and has fewer external interactions. It also means
that by looking at the errno variable if unlink fails you can
generate your own error messages.
Using strace -f on the program when calling the two versions
of deleteConnect() will show more detail
Finally - C is fun, keep going. And all the best
marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
The time for repository upload is approaching... Since, I am only a humble amateur coder, I still have not figured out how to create a proper Debian source package. This means, I will have to create a tar.gz archive as follows: source-tarball.tar.gz | |---cli-backendbackend.c | |---network-manager (lazarus project source files as created by Lazarus) However, I would like to learn to use the maintainer tools to avoid doing it manually. Ideally, dpkg-buildpackage should be able to build a .deb package out of the sources without any other intervention, but those are my current limits. Please be aware that no pre-installation and post-installation scripts will be included. If you want me to write those, it will be yet another challenge. Edward On 20/08/2015, John Morris jmor...@beau.org wrote: On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote: The backends can be integrated into one single executable not to clutter the sudoers file and to increase system efficiency. One suggestion here. Forget sudo and just make the backend suid root like other system utilities of this type. Just make darned sure there is no way to feed it command line input that could allow a root exploit of course. It can check whatever permissions like ownership of the local console/display, membership in wheel, etc. are desired to restrict usage to only some users itself. Maintaining rules in sudoers is less packagable even now that there is a /etc/sudoers.d directory to dump fragments into. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
This is a link for the network-manager GUI running under Devuan 64 bit. http://s9.postimg.org/57gjwuopr/functional_network_manager_GUI.png On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: I am uploading a screenshot of the network manager GUI. As you can see, it is functional, but like anything new, I need more time to fine tune and debug it. On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: Regarding getting rid of requiring sudo, I vaguely remember suids are something that have to do with file permissions. Please, could you instruct me what I should read? Removal of sudo dependency from the entire project is a matter of editing 2 or 3 lines in the Lazarus GUI project. The latter is responsible for calling the backend with root privileges. On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: The time for repository upload is approaching... Since, I am only a humble amateur coder, I still have not figured out how to create a proper Debian source package. This means, I will have to create a tar.gz archive as follows: source-tarball.tar.gz | |---cli-backendbackend.c | |---network-manager (lazarus project source files as created by Lazarus) However, I would like to learn to use the maintainer tools to avoid doing it manually. Ideally, dpkg-buildpackage should be able to build a .deb package out of the sources without any other intervention, but those are my current limits. Please be aware that no pre-installation and post-installation scripts will be included. If you want me to write those, it will be yet another challenge. Edward On 20/08/2015, John Morris jmor...@beau.org wrote: On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote: The backends can be integrated into one single executable not to clutter the sudoers file and to increase system efficiency. One suggestion here. Forget sudo and just make the backend suid root like other system utilities of this type. Just make darned sure there is no way to feed it command line input that could allow a root exploit of course. It can check whatever permissions like ownership of the local console/display, membership in wheel, etc. are desired to restrict usage to only some users itself. Maintaining rules in sudoers is less packagable even now that there is a /etc/sudoers.d directory to dump fragments into. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Regarding getting rid of requiring sudo, I vaguely remember suids are something that have to do with file permissions. Please, could you instruct me what I should read? Removal of sudo dependency from the entire project is a matter of editing 2 or 3 lines in the Lazarus GUI project. The latter is responsible for calling the backend with root privileges. On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: The time for repository upload is approaching... Since, I am only a humble amateur coder, I still have not figured out how to create a proper Debian source package. This means, I will have to create a tar.gz archive as follows: source-tarball.tar.gz | |---cli-backendbackend.c | |---network-manager (lazarus project source files as created by Lazarus) However, I would like to learn to use the maintainer tools to avoid doing it manually. Ideally, dpkg-buildpackage should be able to build a .deb package out of the sources without any other intervention, but those are my current limits. Please be aware that no pre-installation and post-installation scripts will be included. If you want me to write those, it will be yet another challenge. Edward On 20/08/2015, John Morris jmor...@beau.org wrote: On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote: The backends can be integrated into one single executable not to clutter the sudoers file and to increase system efficiency. One suggestion here. Forget sudo and just make the backend suid root like other system utilities of this type. Just make darned sure there is no way to feed it command line input that could allow a root exploit of course. It can check whatever permissions like ownership of the local console/display, membership in wheel, etc. are desired to restrict usage to only some users itself. Maintaining rules in sudoers is less packagable even now that there is a /etc/sudoers.d directory to dump fragments into. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Parsing headaches: I have this chunk of data retrieved from the backend which I need to parse *reliably*. The goal is to read the SSID and the corresponsing signal strength. How should I proceed. This part of code will be done from within Lazarus. Please, be informed that Lazarus generated GUI uses GTK* as a base. The executable can is also statically built which means an increased portability. Executables are about 3 MB. In the past I have written such applications that dwarf what I am doing and still the size is small. Here is what I want to parse: root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID Channel:1 Frequency:2.412 GHz (Channel 1) Quality=70/70 Signal level=-34 dBm Encryption key:on ESSID:EB-TP-LNK67 -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=24/70 Signal level=-86 dBm Encryption key:on ESSID:TNCAPA0332D -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=30/70 Signal level=-80 dBm Encryption key:on ESSID:Home WiFi On 20/08/2015, Steve Litt sl...@troubleshooters.com wrote: On Thu, 20 Aug 2015 22:28:45 +0200 Didier Kryn k...@in2p3.fr wrote: Le 19/08/2015 20:09, Edward Bartolo a écrit : The power inherent in C is due to it not getting in the way of the coder, and I like that. [snip] I didn't review your code. This has been done by others anyway. My problem is that I don't see the big picture. My understanding is that the big picture is that Edward's making a very simple system for dealing with Wifi, both in your house and travelling from hotspot to hotspot. His solution has minimal dependencies and can be run by anyone with just about any Linux configuration. One reason he uses C is because there's no guarantee that Python or Ruby or Lua is installed on the system. Edward's front end obtains a list of Wifi transmitters, together with their signal strengths and encryption type, by spawning iwlist $netdev scanning, where $netdev is typically but not always wlan0. The user chooses one wifi transmitter from the front end, sends its ssid to the back end. The back end looks at its list of known ssids. If this ssid is known, it connects with the known password. Otherwise (and here I might be wrong), the back end signals the front end to query for the new password for the new ssid, and after the user puts in both, the front end sends it to the back end, that now does these two things: 1) Writes a new interface file, for this ssid, for future reference. 2) Connects to this ssid with the inputted password. My understanding is the back end is calling the ifup program, which I believe but am not sure, somewhere calls wpa_supplicant to do the work on Wifi. But I could be wrong about that. It's a pretty simple and, IMHO, robust architecture. One beauty of it is that, although Edward's using Lazarus to make a nice GUI front end for the thing, most people on this list could make a shellscript front end for it. Or zenity. Or Tcl/Tk. Or Python. Or whatever. If I understand correctly, his back end, and only his back end, is in C. I would also like to know what your understanding is of how the things are handled by the cooperative interaction of ifup, ifdown and wpa_supplicant. This is something for which I cannot find a comprehensive description, and I think a full understanding is necessary *prior* to endeavour what you are doing. You and I have a philosophical difference here. All too often, by the time people reach *full* understanding, the project languishes and nothing happens. Prior to the invasion of paid programmers in Open Source, the world was full of software written with a partial understanding, and incrementally improved (or rewritten) later. I wrote the original VimOutliner in 2 days, using Perl, Vim, and shellscripts. Kludge-city. If you'd seen that version 0.10, you'd have laughed. But unlike the other outliners of that era, VimOutliner worked, and worked fast. People started using it. People started depending on it. People a lot smarter than I started improving it. Within two years it was head and shoulders faster and more convenient and easier to use than any other outliner on the planet. That never would have happened without my two day kludge. Look at it another way. I was mouthing off about making a replacement for NetworkManager and Wicd. But I did nothing. Several others were talking about it, but they did nothing. Now Edward did it. There are different kinds of Open Source. When Redhat pays three years salary to Lennart and Kai and the gang, they can afford to take the time for full understanding. When a guy with a day job makes something, he gets it out there and the
Re: [DNG] Systemd Shims
I will now organise the backend's source into separate files using header files and source files. This to make the code more manageable and to ease the life of anyone wanting to fork it. On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: This is a link for the network-manager GUI running under Devuan 64 bit. http://s9.postimg.org/57gjwuopr/functional_network_manager_GUI.png On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: I am uploading a screenshot of the network manager GUI. As you can see, it is functional, but like anything new, I need more time to fine tune and debug it. On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: Regarding getting rid of requiring sudo, I vaguely remember suids are something that have to do with file permissions. Please, could you instruct me what I should read? Removal of sudo dependency from the entire project is a matter of editing 2 or 3 lines in the Lazarus GUI project. The latter is responsible for calling the backend with root privileges. On 20/08/2015, Edward Bartolo edb...@gmail.com wrote: The time for repository upload is approaching... Since, I am only a humble amateur coder, I still have not figured out how to create a proper Debian source package. This means, I will have to create a tar.gz archive as follows: source-tarball.tar.gz | |---cli-backendbackend.c | |---network-manager (lazarus project source files as created by Lazarus) However, I would like to learn to use the maintainer tools to avoid doing it manually. Ideally, dpkg-buildpackage should be able to build a .deb package out of the sources without any other intervention, but those are my current limits. Please be aware that no pre-installation and post-installation scripts will be included. If you want me to write those, it will be yet another challenge. Edward On 20/08/2015, John Morris jmor...@beau.org wrote: On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote: The backends can be integrated into one single executable not to clutter the sudoers file and to increase system efficiency. One suggestion here. Forget sudo and just make the backend suid root like other system utilities of this type. Just make darned sure there is no way to feed it command line input that could allow a root exploit of course. It can check whatever permissions like ownership of the local console/display, membership in wheel, etc. are desired to restrict usage to only some users itself. Maintaining rules in sudoers is less packagable even now that there is a /etc/sudoers.d directory to dump fragments into. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes: The time for repository upload is approaching... Since, I am only a humble amateur coder, I still have not figured out how to create a proper Debian source package. This means, I will have to create a tar.gz archive as follows: source-tarball.tar.gz | |---cli-backendbackend.c | |---network-manager (lazarus project source files as created by Lazarus) However, I would like to learn to use the maintainer tools to avoid doing it manually. Ideally, dpkg-buildpackage should be able to build a .deb package out of the sources without any other intervention, but those are my current limits. dh_make provides an easy way to create 'native' package, ie, one which isn't 'upstream source tree' + 'Debian patches' + 'source package description'. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Roger Leigh rle...@codelibre.net writes:
On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
I'm not picking on this post in particular out of the rest of today's
thread, but I did think this was a good example. While I don't want
to act like a rabid C++ zealot, stuff like this really makes me
shudder due to the fragility and unnecessary complexity for something
which is really trivial.
While the relative safety and security of C string handling can be
debated, I do think the question needs asking: Why not use a language
with proper safe string handling and avoid the issue entirely?
It's only safe until it's refactored to break the existing
assumptions and make it accidentally unsafe. The constants such as 2,
1 plus the strlen() calls are prime candidates for future bugs. It's
not like this /needs/ to be done in C.
The 'constant 2' follows from the fact that the length of the result
string is the length of the path plus the length of the essid string
plus two more bytes/ characters, namely, the '/' and the terminating
zero.
The 'constant 1', in turn, follows from the fact that the essid has to
be appended after the string made up of the path and the added '/'.
That's how string processing in C happens to look like because of how
the language (library, actually) defines a string and because of the
operation supposed to be performed here (combine three different parts,
one with constant length).
Could you perhaps elaborate on what you were writing about? Minus trying
to start a language war, that is. The original author chose C. Because
of this, I wrote and posted a simple example how to do string processing
in C without relying on 'large enough' fixed size buffers.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
It is becoming clear, the frontend GUI will need multithreading. I
will try to use the TThread class to derive a descendant.
On 20/08/2015, Edward Bartolo edb...@gmail.com wrote:
I reorganised the C source code into header files and C code files. I
also tested the backend to make sure the reorganisation of the code
did not impact its functionality. I also included several 'patches' as
suggested and made sure strcat does behave properly.
Needless to state the obvious this code is still in development which
means it is not yet ready to be used. However, for development
evaluation purposes it works.
Here is my humble C code.
-
On 20/08/2015, Roger Leigh rle...@codelibre.net wrote:
On 20/08/2015 11:27, Rainer Weikusat wrote:
Roger Leigh rle...@codelibre.net writes:
On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
I'm not picking on this post in particular out of the rest of today's
thread, but I did think this was a good example. While I don't want
to act like a rabid C++ zealot, stuff like this really makes me
shudder due to the fragility and unnecessary complexity for something
which is really trivial.
While the relative safety and security of C string handling can be
debated, I do think the question needs asking: Why not use a language
with proper safe string handling and avoid the issue entirely?
It's only safe until it's refactored to break the existing
assumptions and make it accidentally unsafe. The constants such as 2,
1 plus the strlen() calls are prime candidates for future bugs. It's
not like this /needs/ to be done in C.
The 'constant 2' follows from the fact that the length of the result
string is the length of the path plus the length of the essid string
plus two more bytes/ characters, namely, the '/' and the terminating
zero.
The 'constant 1', in turn, follows from the fact that the essid has to
be appended after the string made up of the path and the added '/'.
That's how string processing in C happens to look like because of how
the language (library, actually) defines a string and because of the
operation supposed to be performed here (combine three different parts,
one with constant length).
Could you perhaps elaborate on what you were writing about? Minus trying
to start a language war, that is. The original author chose C. Because
of this, I wrote and posted a simple example how to do string processing
in C without relying on 'large enough' fixed size buffers.
The rationale for the use of the constants is fine. But consider that
the code does not document where those numbers come from, and fact that
code to calculate the buffer size and the code to copy data into the
buffer are separate steps. This is where problems can occur. Maybe not
right now, after all you got it right when you wrote it, one would hope.
But when it comes to future modifications, you must update all the
size calculations and constants in line with any changes to how the
buffer is filled, and this is a prime candidate for mistakes and
consequent crashes and/or buffer overflows. When it comes to making
modifications, you or whoever is making the change, needs to work out
exactly what the intent of the orginal code was--i.e. re-derive all the
constants and re-compute them correctly to match the new behaviour.
This is often non-trivial depending on the nature of the string
manipulation.
The fact that C code is a continual source of such quality and security
defects is a clear indication that in general people *don't* get this
right even when they think they are geniuses who know their own code.
This example is short, but people continue to routinely screw up even
stuff this simple, and it only becomes more likely with more complexity.
IMO, stuff like this just doesn't belong in any program that claims to
be secure. Especially in one that's setuid root doing privileged
operations.
When I wrote the schroot(1) tool, which is setuid-root out of necessity
since chroot(2) is privileged, I originally wrote it in C, but converted
it to C++ primarily due to the security considerations, of which
avoiding insecure and buggy string handling was the prime consideration.
It removes this entire class of bugs and security exploits at a
stroke. And if I .reserve() space in a string for efficiency, it's as
efficient as all the manual C manipulations, but safe from overflow, and
if I get
Re: [DNG] Systemd Shims
I reorganised the C source code into header files and C code files. I
also tested the backend to make sure the reorganisation of the code
did not impact its functionality. I also included several 'patches' as
suggested and made sure strcat does behave properly.
Needless to state the obvious this code is still in development which
means it is not yet ready to be used. However, for development
evaluation purposes it works.
Here is my humble C code.
-
On 20/08/2015, Roger Leigh rle...@codelibre.net wrote:
On 20/08/2015 11:27, Rainer Weikusat wrote:
Roger Leigh rle...@codelibre.net writes:
On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
I'm not picking on this post in particular out of the rest of today's
thread, but I did think this was a good example. While I don't want
to act like a rabid C++ zealot, stuff like this really makes me
shudder due to the fragility and unnecessary complexity for something
which is really trivial.
While the relative safety and security of C string handling can be
debated, I do think the question needs asking: Why not use a language
with proper safe string handling and avoid the issue entirely?
It's only safe until it's refactored to break the existing
assumptions and make it accidentally unsafe. The constants such as 2,
1 plus the strlen() calls are prime candidates for future bugs. It's
not like this /needs/ to be done in C.
The 'constant 2' follows from the fact that the length of the result
string is the length of the path plus the length of the essid string
plus two more bytes/ characters, namely, the '/' and the terminating
zero.
The 'constant 1', in turn, follows from the fact that the essid has to
be appended after the string made up of the path and the added '/'.
That's how string processing in C happens to look like because of how
the language (library, actually) defines a string and because of the
operation supposed to be performed here (combine three different parts,
one with constant length).
Could you perhaps elaborate on what you were writing about? Minus trying
to start a language war, that is. The original author chose C. Because
of this, I wrote and posted a simple example how to do string processing
in C without relying on 'large enough' fixed size buffers.
The rationale for the use of the constants is fine. But consider that
the code does not document where those numbers come from, and fact that
code to calculate the buffer size and the code to copy data into the
buffer are separate steps. This is where problems can occur. Maybe not
right now, after all you got it right when you wrote it, one would hope.
But when it comes to future modifications, you must update all the
size calculations and constants in line with any changes to how the
buffer is filled, and this is a prime candidate for mistakes and
consequent crashes and/or buffer overflows. When it comes to making
modifications, you or whoever is making the change, needs to work out
exactly what the intent of the orginal code was--i.e. re-derive all the
constants and re-compute them correctly to match the new behaviour.
This is often non-trivial depending on the nature of the string
manipulation.
The fact that C code is a continual source of such quality and security
defects is a clear indication that in general people *don't* get this
right even when they think they are geniuses who know their own code.
This example is short, but people continue to routinely screw up even
stuff this simple, and it only becomes more likely with more complexity.
IMO, stuff like this just doesn't belong in any program that claims to
be secure. Especially in one that's setuid root doing privileged
operations.
When I wrote the schroot(1) tool, which is setuid-root out of necessity
since chroot(2) is privileged, I originally wrote it in C, but converted
it to C++ primarily due to the security considerations, of which
avoiding insecure and buggy string handling was the prime consideration.
It removes this entire class of bugs and security exploits at a
stroke. And if I .reserve() space in a string for efficiency, it's as
efficient as all the manual C manipulations, but safe from overflow, and
if I get it wrong it'll merely perform another allocation rather than
being exploitable. i.e. it's as efficient as string manipulation in C,
only vastly less complex and with
Re: [DNG] Systemd Shims
On 20/08/2015 11:27, Rainer Weikusat wrote:
Roger Leigh rle...@codelibre.net writes:
On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
I'm not picking on this post in particular out of the rest of today's
thread, but I did think this was a good example. While I don't want
to act like a rabid C++ zealot, stuff like this really makes me
shudder due to the fragility and unnecessary complexity for something
which is really trivial.
While the relative safety and security of C string handling can be
debated, I do think the question needs asking: Why not use a language
with proper safe string handling and avoid the issue entirely?
It's only safe until it's refactored to break the existing
assumptions and make it accidentally unsafe. The constants such as 2,
1 plus the strlen() calls are prime candidates for future bugs. It's
not like this /needs/ to be done in C.
The 'constant 2' follows from the fact that the length of the result
string is the length of the path plus the length of the essid string
plus two more bytes/ characters, namely, the '/' and the terminating
zero.
The 'constant 1', in turn, follows from the fact that the essid has to
be appended after the string made up of the path and the added '/'.
That's how string processing in C happens to look like because of how
the language (library, actually) defines a string and because of the
operation supposed to be performed here (combine three different parts,
one with constant length).
Could you perhaps elaborate on what you were writing about? Minus trying
to start a language war, that is. The original author chose C. Because
of this, I wrote and posted a simple example how to do string processing
in C without relying on 'large enough' fixed size buffers.
The rationale for the use of the constants is fine. But consider that
the code does not document where those numbers come from, and fact that
code to calculate the buffer size and the code to copy data into the
buffer are separate steps. This is where problems can occur. Maybe not
right now, after all you got it right when you wrote it, one would hope.
But when it comes to future modifications, you must update all the
size calculations and constants in line with any changes to how the
buffer is filled, and this is a prime candidate for mistakes and
consequent crashes and/or buffer overflows. When it comes to making
modifications, you or whoever is making the change, needs to work out
exactly what the intent of the orginal code was--i.e. re-derive all the
constants and re-compute them correctly to match the new behaviour.
This is often non-trivial depending on the nature of the string
manipulation.
The fact that C code is a continual source of such quality and security
defects is a clear indication that in general people *don't* get this
right even when they think they are geniuses who know their own code.
This example is short, but people continue to routinely screw up even
stuff this simple, and it only becomes more likely with more complexity.
IMO, stuff like this just doesn't belong in any program that claims to
be secure. Especially in one that's setuid root doing privileged
operations.
When I wrote the schroot(1) tool, which is setuid-root out of necessity
since chroot(2) is privileged, I originally wrote it in C, but converted
it to C++ primarily due to the security considerations, of which
avoiding insecure and buggy string handling was the prime consideration.
It removes this entire class of bugs and security exploits at a
stroke. And if I .reserve() space in a string for efficiency, it's as
efficient as all the manual C manipulations, but safe from overflow, and
if I get it wrong it'll merely perform another allocation rather than
being exploitable. i.e. it's as efficient as string manipulation in C,
only vastly less complex and with safety factored in.
All too often the attitude of C programmers is it'll be perfect and
efficient since I won't screw up. But we all screw up at some point.
And the question then is, what are the consequences of screwing up.
And here, the consequences are severe. But with std::string, are
entirely avoidable. So we both reduce the chance of a screwup by making
the API match our intent exactly without lots of extra make-work to
allocate buffers and unsafely mangle strings, and we also mitigate for
any mistakes in calculations by the failure case being
Re: [DNG] Systemd Shims
On Thu, 2015-08-20 at 07:10 +0100, Edward Bartolo wrote: As it is, the frontend can connect on user request. The user can run the frontend application, click connect and terminate the application and the connection will continue to be functional. This is real KISS in practice but I can also make the application automatically run on startup of the OS. Then the frontend can automatically attempt a connection prompting the user if no connections are set up. Just be sure to ask the user whether a connection is an 'automatically connect' sort of thing or not and save the answer somewhere. Automatically reconnecting to some APs, like your normal home or work one, is great. Others, not so much. In the first case, I can hide the application window altogether only showing it on failing to connect. That would be the 'UNIX Way', if a program has nothing interesting to say it should say nothing. Success is generally considered to be 'not interesting' since it is expected. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Thu, 20 Aug 2015 22:28:45 +0200 Didier Kryn k...@in2p3.fr wrote: Le 19/08/2015 20:09, Edward Bartolo a écrit : The power inherent in C is due to it not getting in the way of the coder, and I like that. [snip] I didn't review your code. This has been done by others anyway. My problem is that I don't see the big picture. My understanding is that the big picture is that Edward's making a very simple system for dealing with Wifi, both in your house and travelling from hotspot to hotspot. His solution has minimal dependencies and can be run by anyone with just about any Linux configuration. One reason he uses C is because there's no guarantee that Python or Ruby or Lua is installed on the system. Edward's front end obtains a list of Wifi transmitters, together with their signal strengths and encryption type, by spawning iwlist $netdev scanning, where $netdev is typically but not always wlan0. The user chooses one wifi transmitter from the front end, sends its ssid to the back end. The back end looks at its list of known ssids. If this ssid is known, it connects with the known password. Otherwise (and here I might be wrong), the back end signals the front end to query for the new password for the new ssid, and after the user puts in both, the front end sends it to the back end, that now does these two things: 1) Writes a new interface file, for this ssid, for future reference. 2) Connects to this ssid with the inputted password. My understanding is the back end is calling the ifup program, which I believe but am not sure, somewhere calls wpa_supplicant to do the work on Wifi. But I could be wrong about that. It's a pretty simple and, IMHO, robust architecture. One beauty of it is that, although Edward's using Lazarus to make a nice GUI front end for the thing, most people on this list could make a shellscript front end for it. Or zenity. Or Tcl/Tk. Or Python. Or whatever. If I understand correctly, his back end, and only his back end, is in C. I would also like to know what your understanding is of how the things are handled by the cooperative interaction of ifup, ifdown and wpa_supplicant. This is something for which I cannot find a comprehensive description, and I think a full understanding is necessary *prior* to endeavour what you are doing. You and I have a philosophical difference here. All too often, by the time people reach *full* understanding, the project languishes and nothing happens. Prior to the invasion of paid programmers in Open Source, the world was full of software written with a partial understanding, and incrementally improved (or rewritten) later. I wrote the original VimOutliner in 2 days, using Perl, Vim, and shellscripts. Kludge-city. If you'd seen that version 0.10, you'd have laughed. But unlike the other outliners of that era, VimOutliner worked, and worked fast. People started using it. People started depending on it. People a lot smarter than I started improving it. Within two years it was head and shoulders faster and more convenient and easier to use than any other outliner on the planet. That never would have happened without my two day kludge. Look at it another way. I was mouthing off about making a replacement for NetworkManager and Wicd. But I did nothing. Several others were talking about it, but they did nothing. Now Edward did it. There are different kinds of Open Source. When Redhat pays three years salary to Lennart and Kai and the gang, they can afford to take the time for full understanding. When a guy with a day job makes something, he gets it out there and the improvements come later. And for my money, I prefer the stuff made by unpaid guys with day jobs: They (we) don't have enough time to make entangled monoliths. This is because these 3 tools are doing a lot of things, and rather well and it is a waste of time and talent to re-invent the wheel. He's not reinventing them at all. He's gluing them together so they're fast and convenient for a user walking his laptop from McDonalds to Starbucks. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Hi Edward,
On 08/19/2015 03:29 PM, Edward Bartolo wrote:
[...]
The C code:
[...]
#define opSave 0
#define opSaveConnect 1
#define opQueryConnect 2
#define opDeleteConnect 3
#define opConnectionConnect 4
#define opDisconnectActiveConnection5
#define opScan 6
#define opLoadExisting 7
[...]
It is maybe more elegant to write
```C
typedef enum {
opSave = 0,
opSaveConnect = 1,
// etc etc
} ops_t;
```
That way you immediately have a well-defined datatype ops_t
for passing your operations around.
Personally, I would treat the numerical value 0 differently,
and start with 1 for the actual operations, like,
```C
typedef enum {
opNone = 0,
opSave = 1,
opSaveConnect = 2,
// etc etc
} ops_t;
```
That way you can write in main():
```C
ops_t switch_item = opNone;
int i;
```
which I like better than assuming that -1 means anything
in particular.
Kind regards,
T.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, 19 Aug 2015 14:29:02 +0100 Edward Bartolo edb...@gmail.com wrote: This is the completed C backend with all functions tested to work. Any suggestions as to modifications are welcome. The C code: Hi Edward, It compiles. Nice! You get a few warnings: == slitt@mydesq2:/d/at/devuan/bartolo$ gcc -Wall backend.c backend.c: In function ‘main’: backend.c:188:8: warning: unused variable ‘out’ [-Wunused-variable] backend.c: In function ‘saveFile’: backend.c:99:2: warning: control reaches end of non-void function [-Wreturn-type] slitt@mydesq2:/d/at/devuan/bartolo$ == If there's a way to attach files to dng emails, that would probably be better, as the code wouldn't word wrap. Did you intend saveFile() to return something? I'll email back as soon as I've looked the code over. Thanks, SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Now comes the hardest part for me: preparing a source package and uploading it. I will need some instructions for that. Some more debugging and both sources for backend and frontend will be ready for upload. -- On 19/08/2015, Edward Bartolo edb...@gmail.com wrote: This is giving some trouble. iwlist wlan0 scanning fails when there is no connection. This is something like needing the egg before the chicken. The application works and can be considered Alpha Stage. I am using it to connect and disconnect but I have to somehow get the neighbouring wifi hotspots :) On 19/08/2015, Steve Litt sl...@troubleshooters.com wrote: On Wed, 19 Aug 2015 14:29:02 +0100 Edward Bartolo edb...@gmail.com wrote: This is the completed C backend with all functions tested to work. Any suggestions as to modifications are welcome. The C code: Hi Edward, It compiles. Nice! You get a few warnings: == slitt@mydesq2:/d/at/devuan/bartolo$ gcc -Wall backend.c backend.c: In function ‘main’: backend.c:188:8: warning: unused variable ‘out’ [-Wunused-variable] backend.c: In function ‘saveFile’: backend.c:99:2: warning: control reaches end of non-void function [-Wreturn-type] slitt@mydesq2:/d/at/devuan/bartolo$ == If there's a way to attach files to dng emails, that would probably be better, as the code wouldn't word wrap. Did you intend saveFile() to return something? I'll email back as soon as I've looked the code over. Thanks, SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
How to learn C if you don't try it?
You have to code in it to learn the lessons.
Just reading a book about it isn't the same.
On 2015-08-19 20:09, Edward Bartolo wrote:
Effectively, you are telling me don't play Russian Roulette with C.
But I like powerful languages that leave the coder in the wilderness
without any hand holding, and C is definitely like that. That is why I
am motivated to use it. The power inherent in C is due to it not
getting in the way of the coder, and I like that.
On 19/08/2015, Rainer Weikusat rainerweiku...@virginmedia.com wrote:
Rainer Weikusat rainerweiku...@virginmedia.com writes:
Edward Bartolo edb...@gmail.com writes:
I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and
the
third step is to correct any potential security issues.
Realistically, the first step is 'make the code function', the second
step is 'graduate from university based on your thesis' and the 3rd
was
called 'heartbleed', IOW, that's not going to happen in this way. If
you're doing string processing in C, try to do it correctly from the
start. That's much easier than retrofitting proper length/ size
handling
onto
some working code.
Example program showing a safe/ secure (and somewhat simplified)
saveFile:
#include alloca.h
#include stdio.h
#include string.h
#define IFACE_TMPL \
auto lo\n \
iface lo inet loopback\n\n \
iface wlan0 inet dhcp\n \
wpa-ssid %s\n \
wpa-psk \%s\\n
#define IFACES_PATH /tmp
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward, This grumpy old man who is so old he started coding when BASIC had line numbers and 8bit Motorola 6800 assembler was state of the art says:- Don't let others harden the code. Do it properly from the start. After many years or using C and C++ my working life is now spent writing Perl. Sometimes it irritates me, but when one line of Perl does what a sheet of A4 full of C can do, well, that cheers me up! And don't forget, you can inline Perl into C to handle those awkward bits, and you can inline C into Perl to make that bit go faster. DaveT On 19/08/15 18:14, Edward Bartolo wrote: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. As anyone can understand, projects, whatever they are, are not completed in one step. Furthermore, debugging is a lengthy process and part of it is removing potential security holes. As to studying other languages, here, you are NOT talking to a youth in his twenties or his teens, but to a 48 year old. Learning a new language is a lengthy process and the ones I know are far more than enough for what I do. Devuan's team of developers is not in any way obliged to accept my code. Any developer who may feel the need to harden the code is free to do so. Thanks On 19/08/2015, Hendrik Boom hend...@topoi.pooq.com wrote: On Wed, Aug 19, 2015 at 06:46:36PM +0200, Laurent Bercot wrote: On 19/08/2015 15:29, Edward Bartolo wrote: This is the completed C backend with all functions tested to work. Any suggestions as to modifications are welcome. OK, someone has to be the bad guy. Let it be me. First, please note that what I'm saying is not meant to discourage you. I appreciate your enthusiasm and willingness to contribute open source software. What I'm saying is meant to make you realize that writing secure software is difficult, especially in C/Unix, which is full of pitfalls. As long as you're unfamiliar with the C/Unix API and all its standard traps, I would advise you to refrain from writing code that is going to be run as root; if you want to be operational right away and contribute system software right now, it's probably easier to stick to higher-level languages, such as Perl, Python, or whatever the FotM interpreted language is at this time. It won't be as satisfying, and the programs won't be as efficient, but it will be safer. Or try some of the less known, but compiled, efficient, strongly and securely type-checked languages such as Modula 3 or OCaml. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 19/08/2015 15:29, Edward Bartolo wrote:
This is the completed C backend with all functions tested to work. Any
suggestions as to modifications are welcome.
OK, someone has to be the bad guy. Let it be me.
First, please note that what I'm saying is not meant to discourage you.
I appreciate your enthusiasm and willingness to contribute open source
software. What I'm saying is meant to make you realize that writing
secure software is difficult, especially in C/Unix, which is full of
pitfalls. As long as you're unfamiliar with the C/Unix API and all its
standard traps, I would advise you to refrain from writing code that
is going to be run as root; if you want to be operational right away
and contribute system software right now, it's probably easier to stick
to higher-level languages, such as Perl, Python, or whatever the FotM
interpreted language is at this time. It won't be as satisfying, and the
programs won't be as efficient, but it will be safer.
On to the code review.
//using namespace std;
This is technically a nit, but philosophically important:
despite of what they've told you, C and C++ are not the same
language at all, and when you're writing C, you're not writing
C++. So, if you're going to write a C program, forget your C++
habits, don't even put them in comments.
#define opSave 0
(...)
#define opLoadExisting 7
As you've been suggested: use an enum.
const
char* path_to_interfaces_files = /etc/network/wifi;
Aesthetics: avoid global variables if you can. If your variable
needs to be used in several functions in your module, declare it
static: static const char *path_... so at least it won't be
exported to other modules if you add some one day.
1) Glib::spawn_sync instead of a pipe stream, provides a slot.
I don't understand this comment. It's C++ syntax again, and about
the Glib module. Please don't try to explain what you're doing with
analogies to other modules in other languages.
2) cmd trying to call an inexistent command still returns a valid pointer!
verify cmd exists before calling exec
... and don't do that, because it creates what is known as a TOCTOU
race condition: you check that the cmd exists, then you use it, but
in the meantime, it could have disappeared. Or the cmd might not
exist when you check it, but would have appeared before you used it.
So, in essence, the check is useless. What you need is a proper error
code when you try to execute a command that does not exist; if
necessary, change your API.
inline int file_exists(char* name) {
return (access(name, F_OK) != -1);
}
And the function isn't actually used in your code either, so you
should simply remove its definition.
if(fgets(buffer, buf_size, pipe) != NULL)
If a line is longer than 127 bytes, it will be silently truncated to
127. Is that what you want? If yes, it's fine, but you should document
the behaviour.
if (out != NULL)
strcat(out, buffer);
else strcpy(out, buffer);
This makes no sense. strcpy() can't be called with a NULL argument
any more than strcat can. What are you trying to accomplish here?
return pclose(pipe);
This is a bit more advanced. When you design a function, or an
interface in general, you want to make it as opaque as possible: you
want to report high-level status to the caller, and hide low-level
details.
Here, the caller does not know you used popen(), and does not want
to know. The caller only wants the result in the out buffer, and
maybe a 0 or 1 return code (possibly with errno set) to know whether
things went OK or not. Returning the result of pclose() leaks your
internal shenanigans to the caller: don't do that. Instead, design
a proper interface (e.g. OK - nonzero, NOK - 0 with errno set) and
write your function so that it implements exactly that interface.
int saveFile(char* essid, char* pw) //argv[2], argv[3]
{
char ifilename[1024];
strcpy(ifilename, path_to_interfaces_files);
strcat(ifilename, /);
strcat(ifilename, essid);
Boom. You're dead.
I'm stopping here, but you're making this mistake in all the rest
of your code, and this is the *single worst mistake* to make as a
C programmer: a buffer overflow. A buffer overflow is the main cause
of security issues all over the computer world, and you cannot, you
ABSOLUTELY CANNOT, publish a piece of code that contains one, especially
when said piece of code is supposed to run as root.
ifilename is 1024 bytes long. You are assuming that essid, and
whatever comes afterwards, will fit into 1024 bytes. This is true
for normal inputs, which is certainly what you tested your program
against, but the input is given as a command line argument to your
program: you do not control the input. *The user* controls the input.
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. Realistically, the first step is 'make the code function', the second step is 'graduate from university based on your thesis' and the 3rd was called 'heartbleed', IOW, that's not going to happen in this way. If you're doing string processing in C, try to do it correctly from the start. That's much easier than retrofitting proper length/ size handling onto some working code. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, 19 Aug 2015 18:25:45 +0100 Rainer Weikusat rainerweiku...@virginmedia.com wrote: Edward Bartolo edb...@gmail.com writes: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. Realistically, the first step is 'make the code function', the second step is 'graduate from university based on your thesis' and the 3rd was called 'heartbleed', IOW, that's not going to happen in this way. If you're doing string processing in C, try to do it correctly from the start. That's much easier than retrofitting proper length/ size handling onto some working code. LOL, hey guys, cut Edward some slack. He whipped this up in one day, when the rest of us, especially I, were sitting on our hands *with respect to a Wifi tool*. He'll obviously change the strcpy() to strncpy(), or buf=(char *) malloc(sizeof(char) * strlen(src)) later, and if he doesn't, we will. In The Cathedral and the Bizaar, Eric Raymond says the following: == When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the forseeable future. == In one day, Edward has accomplished the preceding. With very simple code having few if any dependencies. And it's short enough that retrofitting won't be a problem. Having no wifi on this box, I haven't been able to run his thing yet, but I bet I could run it without a front end, just by making a couple test-jig shellscripts. Edward, you just keep doing what you're doing. Any rough edges or insecurities you don't smooth out, there's an army of people who can do that. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Laurent Bercot ska-de...@skarnet.org writes:
[...]
int saveFile(char* essid, char* pw) //argv[2], argv[3]
{
char ifilename[1024];
strcpy(ifilename, path_to_interfaces_files);
strcat(ifilename, /);
strcat(ifilename, essid);
Boom. You're dead.
[...]
ifilename is 1024 bytes long. You are assuming that essid, and
whatever comes afterwards, will fit into 1024 bytes. This is true
for normal inputs, which is certainly what you tested your program
against, but the input is given as a command line argument to your
program: you do not control the input. *The user* controls the input.
And a malicious user could very well give an essid argument that is
longer than 1024 bytes.
That's presumably not much of a problem because a single user attacking
his own system is probably not much of a problem: Break whatever you
like. It's yours.
A more interesting issue is that 'essid' is likely something harvested
from AP broadcasting one. According to a quick check, a valid ESSID can
be at most 32 octets and it can't be more than 256 octets even if
someone configures something he controls to send invalid ESSIDs and the
software processing these doesn't check since there's a 1 byte length
field. This means the code above, when used as intended, it likely
'accidentally safe' but relying on 'lucky accidents' like this is
nevertheless an extremely bad idea.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, Aug 19, 2015 at 06:46:36PM +0200, Laurent Bercot wrote: On 19/08/2015 15:29, Edward Bartolo wrote: This is the completed C backend with all functions tested to work. Any suggestions as to modifications are welcome. OK, someone has to be the bad guy. Let it be me. First, please note that what I'm saying is not meant to discourage you. I appreciate your enthusiasm and willingness to contribute open source software. What I'm saying is meant to make you realize that writing secure software is difficult, especially in C/Unix, which is full of pitfalls. As long as you're unfamiliar with the C/Unix API and all its standard traps, I would advise you to refrain from writing code that is going to be run as root; if you want to be operational right away and contribute system software right now, it's probably easier to stick to higher-level languages, such as Perl, Python, or whatever the FotM interpreted language is at this time. It won't be as satisfying, and the programs won't be as efficient, but it will be safer. Or try some of the less known, but compiled, efficient, strongly and securely type-checked languages such as Modula 3 or OCaml. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes: [...] strcpy(text, auto lo\n); fprintf(fp, text); None of these 2 line pairs is really needed: You can always just use the literal string directly, eg, fputs(auto lo\n, fp); [...] char command[1024]; strcpy(command, /sbin/iwlist wlan0 scanning | /bin/grep ESSID); int q = exec(command, s); or exec(/sbin/iwlist wlan0 scanning | /bin/grep ESSID, s) here. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Effectively, you are telling me don't play Russian Roulette with C.
But I like powerful languages that leave the coder in the wilderness
without any hand holding, and C is definitely like that. That is why I
am motivated to use it. The power inherent in C is due to it not
getting in the way of the coder, and I like that.
On 19/08/2015, Rainer Weikusat rainerweiku...@virginmedia.com wrote:
Rainer Weikusat rainerweiku...@virginmedia.com writes:
Edward Bartolo edb...@gmail.com writes:
I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and the
third step is to correct any potential security issues.
Realistically, the first step is 'make the code function', the second
step is 'graduate from university based on your thesis' and the 3rd was
called 'heartbleed', IOW, that's not going to happen in this way. If
you're doing string processing in C, try to do it correctly from the
start. That's much easier than retrofitting proper length/ size handling
onto
some working code.
Example program showing a safe/ secure (and somewhat simplified)
saveFile:
#include alloca.h
#include stdio.h
#include string.h
#define IFACE_TMPL \
auto lo\n \
iface lo inet loopback\n\n \
iface wlan0 inet dhcp\n \
wpa-ssid %s\n \
wpa-psk \%s\\n
#define IFACES_PATH /tmp
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Steve Litt sl...@troubleshooters.com writes: On Wed, 19 Aug 2015 18:25:45 +0100 Rainer Weikusat rainerweiku...@virginmedia.com wrote: Edward Bartolo edb...@gmail.com writes: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. Realistically, the first step is 'make the code function', the second step is 'graduate from university based on your thesis' and the 3rd was called 'heartbleed', IOW, that's not going to happen in this way. If you're doing string processing in C, try to do it correctly from the start. That's much easier than retrofitting proper length/ size handling onto some working code. LOL, hey guys, cut Edward some slack. He whipped this up in one day, when the rest of us, especially I, were sitting on our hands *with respect to a Wifi tool*. I was commenting on the code and the methodology and not on him: As I tried to demonstrate with the example I posted, it's not really difficult to get it right from the start. [...] In The Cathedral and the Bizaar, Eric Raymond says the following: == When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the forseeable future. == In The Cathedral of the Bizarre (love this typo), it usually works like this: 1. The code is buggy (for a certain definition of buggy) because whoever originally wrote it couldn't be bothered to deal with the issue. Because of this, should you be forced to fix it, don't bother sharing the fix with the author: If he had cared about that, you wouldn't have had to fix it and, and since he doesn't, he (at best) won't care about you fix, anyway. 2. The code lacks features because none of the people who control it were interested in them. In case you add some, don't bother trying to share you changes: The people who control the code won't exactly be happy when others suddenly try to exercise some control, too and since they don't need the feature, they (at best) won't care. Should someone sufficiently important need it in future, they'll reimplement it. Things may have worked differently in the early days of Linux (the project) but that's because Linus Torvalds is an outstanding project manager (among other things) but since Linux turned into a billion dollar business, it stopped working in this way a long time ago. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Rainer Weikusat rainerweiku...@virginmedia.com writes:
Edward Bartolo edb...@gmail.com writes:
I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and the
third step is to correct any potential security issues.
Realistically, the first step is 'make the code function', the second
step is 'graduate from university based on your thesis' and the 3rd was
called 'heartbleed', IOW, that's not going to happen in this way. If
you're doing string processing in C, try to do it correctly from the
start. That's much easier than retrofitting proper length/ size handling onto
some working code.
Example program showing a safe/ secure (and somewhat simplified)
saveFile:
#include alloca.h
#include stdio.h
#include string.h
#define IFACE_TMPL \
auto lo\n \
iface lo inet loopback\n\n \
iface wlan0 inet dhcp\n \
wpa-ssid %s\n \
wpa-psk \%s\\n
#define IFACES_PATH /tmp
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 19/08/2015 19:14, Edward Bartolo wrote: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. I'm sorry, but no, this is not how it works. The first step, as you say, is to make the code function, and that means *without* security issues in the design. You can't add security in the third step; security cannot be an afterthought, it has to be an integral part of the design. Correcting potential security issues may force you to change your API entirely, or rewrite significant portions of your code. This is often impractical, and you may miss some of the issues. As anyone can understand, projects, whatever they are, are not completed in one step. Of course projects are not completed in one step. You submitted a code for review, I gave you a review: this is part of the process, let's get on to the next step. As to studying other languages, here, you are NOT talking to a youth in his twenties or his teens, but to a 48 year old. Learning a new language is a lengthy process and the ones I know are far more than enough for what I do. I don't care what your age is, or where you live, or what gender you are, or anything else about you. I'm only looking at the code and saying what I think of the code. If you want to write in C, then please take my review into account: it may not be to your liking, but it is honest. Or use whatever other language you want: I won't know it well enough to review you, so I'll be off your back. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, Aug 19, 2015 at 01:50:22PM -0400, Steve Litt wrote: On Wed, 19 Aug 2015 18:25:45 +0100 Rainer Weikusat rainerweiku...@virginmedia.com wrote: Edward Bartolo edb...@gmail.com writes: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. Realistically, the first step is 'make the code function', the second step is 'graduate from university based on your thesis' and the 3rd was called 'heartbleed', IOW, that's not going to happen in this way. If you're doing string processing in C, try to do it correctly from the start. That's much easier than retrofitting proper length/ size handling onto some working code. LOL, hey guys, cut Edward some slack. He whipped this up in one day, when the rest of us, especially I, were sitting on our hands *with respect to a Wifi tool*. He'll obviously change the strcpy() to strncpy(), or buf=(char *) malloc(sizeof(char) * strlen(src)) later, and if he doesn't, we will. In The Cathedral and the Bizaar, Eric Raymond says the following: == When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the forseeable future. == In one day, Edward has accomplished the preceding. With very simple code having few if any dependencies. And it's short enough that retrofitting won't be a problem. Having no wifi on this box, I haven't been able to run his thing yet, but I bet I could run it without a front end, just by making a couple test-jig shellscripts. Edward, you just keep doing what you're doing. Any rough edges or insecurities you don't smooth out, there's an army of people who can do that. SteveT Despite my comments about programming languages and reliability, I agree with this. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Hi Edward, On 08/19/2015 03:29 PM, Edward Bartolo wrote: This is the completed C backend with all functions tested to work. Any suggestions as to modifications are welcome. [...] A word of advice, do not take critizism personal, even if it's harsh, and especially not if it's coming from people who didn't have the nerve to write this important software (because they have even more important daytime jobs where they either count dollar bills for the 1% or work as sales engineer in marketing of rubber products), but now that someone has proposed an actual solution, act all super smart. ;-))) Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 19/08/2015, Rainer Weikusat rainerweiku...@virginmedia.com wrote: [...] p_len = strlen(IFACES_PATH); e_len = strlen(essid); path = alloca(p_len + e_len + 2); strcpy(path, IFACES_PATH); path[p_len] = '/'; strcpy(path + p_len + 1, essid); [...] You might want to do some error checking here :-) path = alloca(p_len + e_len + 2); strcpy(path + p_len + 1, essid); Actually, no. 'alloca' instructs the compiler to generate code to reserve a certain amount of space in the current stack frame and return a pointer to it. This it will do by simple arithmetic and in case the pro forma reserved space isn't really available yet, the stack is supposed to be grown accordingly by the kernel (for a single-threaded process). If this doesn't work, an attempt to use it will segfault. There are some more interesting error scenarios for large allocations, certain ways of using them and multi-threaded processes (specifically, it's possible to skip over the guard page at the bottom of the thread stack and write into the memory immediatley below that, ie, overwrite the top of the stack of some other thread or something totally unrelated). Some people strongly dislike this interface because of these be sensible or BEWARE of the consequences properties. But being sensible is easy for simple cases (such as here) and 'stack allocation' is IMHO preferably for relatively small things as it will be freed automatically and won't cause unpredictable, global side effects on the malloc heap. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 19/08/2015 17:39, Rainer Weikusat wrote:
#define IFACE_TMPL \
auto lo\n \
iface lo inet loopback\n\n \
iface wlan0 inet dhcp\n \
wpa-ssid %s\n \
wpa-psk \%s\\n
#define IFACES_PATH /tmp
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
fp = fopen(path, ab+);
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}
int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
I'm not picking on this post in particular out of the rest of today's
thread, but I did think this was a good example. While I don't want to
act like a rabid C++ zealot, stuff like this really makes me shudder due
to the fragility and unnecessary complexity for something which is
really trivial.
While the relative safety and security of C string handling can be
debated, I do think the question needs asking: Why not use a language
with proper safe string handling and avoid the issue entirely? It's
only safe until it's refactored to break the existing assumptions and
make it accidentally unsafe. The constants such as 2, 1 plus the
strlen() calls are prime candidates for future bugs. It's not like this
/needs/ to be done in C.
void saveFile(const std::string essid, const std::string pw)
{
std::string path(IFACES_PATH);
path += '/';
path += essid;
std::ofstream fp(path);
if (fp)
{
boost::format fmt(IFACE_TMPL);
fmt % essid % pw;
fp fmt.str() std::flush;
}
}
No leaks. No buffer overflows. Safe formatting. No file handle leaks.
And it's readable--the intent is obvious since there's no extraneous
buffer memory management. And it will compile down to something
equivalent or even more efficient.
If you use std::string you can still work directly with C functions
using const char *--just use the .c_str() method and you get a
suitable pointer.
In my own code I use boost.filesystem, so rather than using std::string
path you could then do
path p = IFACES_PATH / essid;
and have the path concatentation handled directly, and then use
p.string() to get a string back. Even safer and more maintainable--work
with path components directly rather than mangling strings.
void saveFile(const std::string essid, const std::string pw)
{
path p = IFACES_PATH / essid;
std::ofstream fp(p.string();
if (fp)
{
boost::format fmt(IFACE_TMPL);
fmt % essid % pw;
fp fmt.str() std::flush;
}
}
This is obviously easier and faster to write and maintain, so your
energies are spent productively on the problem at hand, rather than
faffing around with manual buffer management.
And if efficiency isn't the prime consideration (and given the context,
it isn't), then an interpreted language is likely an even better choice.
Regards,
Roger
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, Aug 19, 2015 at 06:14:38PM +0100, Edward Bartolo wrote: ... As to studying other languages, here, you are NOT talking to a youth in his twenties or his teens, but to a 48 year old. Learning a new language is a lengthy process and the ones I know are far more than enough for what I do. And you are not talking to a youth in his forties, but to a 68-year-old. I find that choice of language is often one of the most important steps in achieving reliable code, and I am still looking for better ones. Whether devuan wants to hitch any part of its wagon to another language is, of course, a separate question, as is whether it is the most effective for the job. I will point out that OCaml is currently available in devuan, and, as far as I know, it does not depend on systemd. Modula3, has not found its way into the Debi/vuan repositories. It is available elsewhere, where .deb's are provided for i386 and AMD64. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, Aug 19, 2015 at 07:08:25PM +0100, Rainer Weikusat wrote: Steve Litt sl...@troubleshooters.com writes: On Wed, 19 Aug 2015 18:25:45 +0100 Rainer Weikusat rainerweiku...@virginmedia.com wrote: Edward Bartolo edb...@gmail.com writes: I am not assuming anything and understand the risks of buffer overflows. The first step I am taking is to make the code function. The second step is further debug it until it behaves properly and the third step is to correct any potential security issues. Realistically, the first step is 'make the code function', the second step is 'graduate from university based on your thesis' and the 3rd was called 'heartbleed', IOW, that's not going to happen in this way. If you're doing string processing in C, try to do it correctly from the start. That's much easier than retrofitting proper length/ size handling onto some working code. LOL, hey guys, cut Edward some slack. He whipped this up in one day, when the rest of us, especially I, were sitting on our hands *with respect to a Wifi tool*. I was commenting on the code and the methodology and not on him: As I tried to demonstrate with the example I posted, it's not really difficult to get it right from the start. [...] In The Cathedral and the Bizaar, Eric Raymond says the following: == When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the forseeable future. == In The Cathedral of the Bizarre (love this typo), it usually works like this: 1. The code is buggy (for a certain definition of buggy) because whoever originally wrote it couldn't be bothered to deal with the issue. Because of this, should you be forced to fix it, don't bother sharing the fix with the author: If he had cared about that, you wouldn't have had to fix it and, and since he doesn't, he (at best) won't care about you fix, anyway. 2. The code lacks features because none of the people who control it were interested in them. In case you add some, don't bother trying to share you changes: The people who control the code won't exactly be happy when others suddenly try to exercise some control, too and since they don't need the feature, they (at best) won't care. Should someone sufficiently important need it in future, they'll reimplement it. Things may have worked differently in the early days of Linux (the project) but that's because Linus Torvalds is an outstanding project manager (among other things) but since Linux turned into a billion dollar business, it stopped working in this way a long time ago. Isn't it our calling at devuan to bring those days back? I know, it's probably tilting at windmills. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Wed, Aug 19, 2015 at 06:19:41PM +0100, Rainer Weikusat wrote:
Laurent Bercot ska-de...@skarnet.org writes:
[...]
int saveFile(char* essid, char* pw) //argv[2], argv[3]
{
char ifilename[1024];
strcpy(ifilename, path_to_interfaces_files);
strcat(ifilename, /);
strcat(ifilename, essid);
Boom. You're dead.
Sorry if I sound harsh, but I can get sensitive when someone tell me I'm dead.
-- Hendrik Boom
:-)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Hello
Now, I should think, the buffer overruns should not be possible, but I
am open to criticism. Buffer overruns are not something to be proud of
and correction when taken appropriately is a blessing.
Now, I will sleep as I am totally exhausted from coding all day long.
Well, you deserved a good rest - congratulations for making the
effort to learn something and contributing software. Doing something
almost always beats talking about it.
Here is some feedback from me - for tomorrow, use or don't use.
* The main() function is special, returning negative values
in it doesn't have the expected results - generally values
between 0 and 255 are possible. Convention is 0 is success,
1 some sort of alternative success and larger numbers a
failure. /usr/include/sysexits.h defines some common failure
modes, though not that many applications use those codes.
Anyway - try for yourself: run a program which returns a negative
value and then use echo $? after it completes to see what
actually made it back
* In your deletion logic you use
int deleteConnect(char* essid) //argv[2]
{
//char* s = 0;
char command[1024];
strcpy(command, /bin/rm /etc/network/wifi/);
strcat(command, essid);
int q = exec(command, 0);
//printf(s);
return q;
}
So it turns out there is a system call which is used internally
by rm to do the deletion. It is called unlink (man 2 unlink)
Using it means you could do
int deleteConnect(char* essid) //argv[2]
{
char command[SIZE];
int result;
result = snprintf(command, SIZE, /etc/network/wifi/%s, essid)
if(result = SIZE){
return -1;
}
return unlink(command);
}
Code size-wise it doesn't look that different, but instead of
creating a shell process which then launches a rm process which
then does the unlink, you can do the unlink yourself - which
is faster and has fewer external interactions. It also means
that by looking at the errno variable if unlink fails you can
generate your own error messages.
Using strace -f on the program when calling the two versions
of deleteConnect() will show more detail
Finally - C is fun, keep going. And all the best
marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote: The backends can be integrated into one single executable not to clutter the sudoers file and to increase system efficiency. One suggestion here. Forget sudo and just make the backend suid root like other system utilities of this type. Just make darned sure there is no way to feed it command line input that could allow a root exploit of course. It can check whatever permissions like ownership of the local console/display, membership in wheel, etc. are desired to restrict usage to only some users itself. Maintaining rules in sudoers is less packagable even now that there is a /etc/sudoers.d directory to dump fragments into. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
At the moment I am stuck trying to use sudo to run ifup from within my
frontend. This testing phase is important as I need to ascertain
myself that the class I am using can actually capture CLI output.
If anyone from Devuan knows of a Lazarus function that I can use to
capture the output of an external program running with root
privileges, it will be much of an impulse for my coding exercise.
I am using the TProcess class. The program runs sudo -s ifup wlan0
successfully but it is failing to capture the CLI output.
In the meantime I will continue debugging until I find a way of succeeding.
Edward.
On 18/08/2015, Edward Bartolo edb...@gmail.com wrote:
Lazarus frontend can now run external programs capturing their textual
output. Hopefully, within a few days, the frontend will be Alpha. :)
On 17/08/2015, Edward Bartolo edb...@gmail.com wrote:
The Lazarus backend interface unit is as follows but still unfinished:
unit backend;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, stdctrls;
procedure Backend_Save(essid, pw: string);
procedure Backend_Save_Connect(essid, pw: string);
function Backend_Query_Connect(connection: string; var pw: string):
boolean;
function Backend_Delete_Connect(essid: string): boolean;
function Backend_Connection_Connect(essid: string): boolean;
function Backend_Disconnect_Active_Connection: boolean;
procedure Backend_Scan(aListBox: TListBox);
procedure Backend_Load_Existing(aListBox: TListBox);
implementation
const
opSave = 0;
opSaveConnect = 1;
opQueryConnect = 2;
opDeleteConnect = 3;
opConnectionConnect = 4;
opDisconnectActiveConnection = 5;
opScan = 6;
opLoadExisting = 7;
procedure Backend_Save(essid, pw: string);
begin
// backend opSave essid pw
end;
procedure Backend_Save_Connect(essid, pw: string);
begin
// backend opSaveConnect essid pw
end;
function Backend_Query_Connect(connection: string; var pw:string):
boolean;
begin
// backend opQueryConnect essid pw
end;
function Backend_Delete_Connect(essid: string): boolean;
begin
// backend opDeleteConnect essid
result := true;
end;
function Backend_Connection_Connect(essid: string): boolean;
begin
// backend opConnectionConnect essid
end;
function Backend_Disconnect_Active_Connection: boolean;
begin
// backend opDisconnectActiveConnection
end;
procedure Backend_Scan(aListBox: TListBox);
begin
// backend opScan stringlist
end;
procedure Backend_Load_Existing(aListBox: TListBox);
begin
// backend opLoadExisting stringlist
end;
end.
-
On 17/08/2015, Edward Bartolo edb...@gmail.com wrote:
The Progress of My Coding Till Now:
I am attaching two images of the GUI's main window and the only
dialog. The GUI is programmed in Lazarus Pascal.
The backend is in C. The code till now, although it doesn't do anything
useful.
--
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
using namespace std;
#define opSave 0
#define opSaveConnect 1
#define opQueryConnect 2
#define opDeleteConnect 3
#define opConnectionConnect 4
#define opDisconnectActiveConnection5
#define opScan 6
#define opLoadExisting 7
/*
1) Glib::spawn_sync instead of a pipe stream, provides a slot.
2) cmd trying to call an inexistent command still returns a valid
pointer!
verify cmd exists before calling exec
*/
inline bool file_exists(char* name) {
return (access(name, F_OK) != -1);
}
int exec(const char* cmd, char* out)
{
const int buf_size = 128;
FILE * pipe = popen(cmd, r);
char buffer[buf_size];
while(!feof(pipe)) {
if(fgets(buffer, buf_size, pipe) != NULL)
{
if (out != NULL)
strcat(out, buffer);
else strcpy(out, buffer);
}
}
return pclose(pipe);
}
int main(int argc, char *argv[])
{
char *out = 0;
int switch_item = -1;
if (argc 1) switch_item = atoi(argv[1]);
switch (switch_item) {
case opSave:
//saveFile(argv[2], argv[3]);
exec(cat /etc/network/interfaces, out);
//out[0] = ' ';
printf(out);
return 0;
case opSaveConnect:
//saveFile(argv[2], argv[3]);
//Connect(argv[2]);
return 0;
case opQueryConnect:
return 0;
case opDeleteConnect:
Re: [DNG] Systemd Shims
Lazarus frontend can now run external programs capturing their textual
output. Hopefully, within a few days, the frontend will be Alpha. :)
On 17/08/2015, Edward Bartolo edb...@gmail.com wrote:
The Lazarus backend interface unit is as follows but still unfinished:
unit backend;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, stdctrls;
procedure Backend_Save(essid, pw: string);
procedure Backend_Save_Connect(essid, pw: string);
function Backend_Query_Connect(connection: string; var pw: string):
boolean;
function Backend_Delete_Connect(essid: string): boolean;
function Backend_Connection_Connect(essid: string): boolean;
function Backend_Disconnect_Active_Connection: boolean;
procedure Backend_Scan(aListBox: TListBox);
procedure Backend_Load_Existing(aListBox: TListBox);
implementation
const
opSave = 0;
opSaveConnect = 1;
opQueryConnect = 2;
opDeleteConnect = 3;
opConnectionConnect = 4;
opDisconnectActiveConnection = 5;
opScan = 6;
opLoadExisting = 7;
procedure Backend_Save(essid, pw: string);
begin
// backend opSave essid pw
end;
procedure Backend_Save_Connect(essid, pw: string);
begin
// backend opSaveConnect essid pw
end;
function Backend_Query_Connect(connection: string; var pw:string): boolean;
begin
// backend opQueryConnect essid pw
end;
function Backend_Delete_Connect(essid: string): boolean;
begin
// backend opDeleteConnect essid
result := true;
end;
function Backend_Connection_Connect(essid: string): boolean;
begin
// backend opConnectionConnect essid
end;
function Backend_Disconnect_Active_Connection: boolean;
begin
// backend opDisconnectActiveConnection
end;
procedure Backend_Scan(aListBox: TListBox);
begin
// backend opScan stringlist
end;
procedure Backend_Load_Existing(aListBox: TListBox);
begin
// backend opLoadExisting stringlist
end;
end.
-
On 17/08/2015, Edward Bartolo edb...@gmail.com wrote:
The Progress of My Coding Till Now:
I am attaching two images of the GUI's main window and the only
dialog. The GUI is programmed in Lazarus Pascal.
The backend is in C. The code till now, although it doesn't do anything
useful.
--
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
using namespace std;
#define opSave 0
#define opSaveConnect1
#define opQueryConnect 2
#define opDeleteConnect 3
#define opConnectionConnect 4
#define opDisconnectActiveConnection 5
#define opScan 6
#define opLoadExisting 7
/*
1) Glib::spawn_sync instead of a pipe stream, provides a slot.
2) cmd trying to call an inexistent command still returns a valid
pointer!
verify cmd exists before calling exec
*/
inline bool file_exists(char* name) {
return (access(name, F_OK) != -1);
}
int exec(const char* cmd, char* out)
{
const int buf_size = 128;
FILE * pipe = popen(cmd, r);
char buffer[buf_size];
while(!feof(pipe)) {
if(fgets(buffer, buf_size, pipe) != NULL)
{
if (out != NULL)
strcat(out, buffer);
else strcpy(out, buffer);
}
}
return pclose(pipe);
}
int main(int argc, char *argv[])
{
char *out = 0;
int switch_item = -1;
if (argc 1) switch_item = atoi(argv[1]);
switch (switch_item) {
case opSave:
//saveFile(argv[2], argv[3]);
exec(cat /etc/network/interfaces, out);
//out[0] = ' ';
printf(out);
return 0;
case opSaveConnect:
//saveFile(argv[2], argv[3]);
//Connect(argv[2]);
return 0;
case opQueryConnect:
return 0;
case opDeleteConnect:
break;
case opConnectionConnect:
break;
case opDisconnectActiveConnection:
break;
case opScan:
break;
case opLoadExisting:
return 0;
}
return -1; // parameter not in range
}
On 17/08/2015, Rainer Weikusat
Re: [DNG] Systemd Shims
Le 18/08/2015 12:49, Edward Bartolo a écrit : At the moment I am stuck trying to use sudo to run ifup from within my frontend. Just in case, here are a few things I know about wpa_supplicant: wpa_supplicant does ifups automatically when it connects to a wifi station. If an interface name is not specified in wpa_supplicant.conf, in the proper section of this station, it ifups the interface named default. Therefore you shouldn't ifup yourself. You only need to fill the configuration files, wpa_supplicant.conf, via the control socket and interfaces by some method probably involving sudo. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes: At the moment I am stuck trying to use sudo to run ifup from within my frontend. This testing phase is important as I need to ascertain myself that the class I am using can actually capture CLI output. If anyone from Devuan knows of a Lazarus function that I can use to capture the output of an external program running with root privileges, it will be much of an impulse for my coding exercise. http://www.freepascal.org/docs-html/rtl/unix/popen.html That's very likely not the most sensible solution as it likely incorporates both C stdio and executing an intermediate /bin/sh but it should be the simplest. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Successfully connected to wifi with the frontend and backend communicating. But there are still problems regarding text capture. It will take more tedious debugging time... but in the end, it should work, hopefully. On 18/08/2015, Edward Bartolo edb...@gmail.com wrote: A) I am at the stage of trying to understand these: a) iw_sockets_open b) iw_get_range_info c) iw_scan The goal is to avoid to have the least number of dependencies. B) I have yet another tempting idea. This is to use only one file for the essids and corresponding passwords. However, this would force me to somehow trick ifup into thinking it is being passed an interfaces file instead of the output from an executable. I found it. But this does work. :) cat /etc/network/interfaces | ifup wlan0 What do you think? Now I can use only one file for all the wifi hotspots. I think, it should be a text file only writable by root. As wifi passwords are effective only near their respective wifi hot spots, I shouldn't think, I need to use encryption to make the file unreadable. P.S. Before the actual uploading of the source, I will need direction and help. I will need to know which developer tools I will need to use to import my pascal project together with the other C source files. I will also need to know what to include so that the source would be compatible with dpkg-buildpackage. Edward On 18/08/2015, Edward Bartolo edb...@gmail.com wrote: A) I am at the stage of trying to understand these: a) iw_sockets_open b) iw_get_range_info c) iw_scan The goal is to avoid to have the least number of dependencies. B) I have yet another tempting idea. This is to use only one file for the essids and corresponding passwords. However, this would force me to somehow trick ifup into thinking it is being passed an interfaces file instead of the output from an executable. Here is the command: ifup wlan0 -i $(tricky-executable(essid)) tricky-executable would pass a series of text lines as they would appear in a dedicated interfaces file. I found it: it is not the above as that does not work. But this does work. :) cat /etc/network/interfaces | ifup wlan0 What do you think. On 18/08/2015, Steve Litt sl...@troubleshooters.com wrote: On Tue, 18 Aug 2015 11:49:40 +0100 Edward Bartolo edb...@gmail.com wrote: At the moment I am stuck trying to use sudo to run ifup from within my frontend. I think the backend should do the ifup. ifup is part of the apps core responsibility, not a way of presenting to the user. Just have the front end tell the back end to do whatever's necessary (ifup, ifdown, rewrite a config file and ifup, etc). SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Hi Edward, I've never used Lazarus, origin in the missing Kylix C/C++ for GNU/Linux, at the same time origin in Borland C/C++and Delphi Pascal for MS Windows. I usually use QtCreator, and sometimes Anjuta. So, i can't help you. Anyway, i think thatfor your purpose the relevance is not in the frontend, but rather in the backend. This is written in C, and you can always use a shell script via: system(here_put_the_shell_script); Perhaps it will be usefull for you... Regards, Aitor. On 18/08/15 14:00, Edward Bartoloedb...@gmail.com wrote: If anyone from Devuan knows of a Lazarus function that I can use to capture the output of an external program running with root privileges, it will be much of an impulse for my coding exercise. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
If there is a technical reason as to why not to use ifup, please inform me. On 18/08/2015, Edward Bartolo edb...@gmail.com wrote: Maybe setting poStderrToOutPut BINGO! That was it. Now it can capture the output even as root. I had a look at wpa_supplicant.conf and found it is an XML file having to do with dbus apparently. For the last five years I have been using ifup manually to connect whenever I didn't have a network manager. It always worked and the connection is stable even for weak signals. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Maybe setting poStderrToOutPut BINGO! That was it. Now it can capture the output even as root. I had a look at wpa_supplicant.conf and found it is an XML file having to do with dbus apparently. For the last five years I have been using ifup manually to connect whenever I didn't have a network manager. It always worked and the connection is stable even for weak signals. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Edward Bartolo edb...@gmail.com writes: Maybe setting poStderrToOutPut BINGO! That was it. Now it can capture the output even as root. There's a predefined input stream available for capturing output on file descriptor 2/ stderr http://www.freepascal.org/docs-html/fcl/process/tprocess.stderr.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
James Powell james4...@hotmail.com writes: While there are packages that can be invisible and unintrusive into the system, there are some that cannot. The problem is responsibility. Who wants to remain responsible for boot scripts? Upstream or vendor? Who wants responsibility for providing interoperability between projects? Upstream or downstream bazaar? Who wants responsibility for the userland? Upstream or the downstream bazaar? It's possible to frame this in more technical terms: Who'll end up doing system integration, system integrators or application developers? The answer should (hopefully) be obvious. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
The Lazarus backend interface unit is as follows but still unfinished:
unit backend;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, stdctrls;
procedure Backend_Save(essid, pw: string);
procedure Backend_Save_Connect(essid, pw: string);
function Backend_Query_Connect(connection: string; var pw: string): boolean;
function Backend_Delete_Connect(essid: string): boolean;
function Backend_Connection_Connect(essid: string): boolean;
function Backend_Disconnect_Active_Connection: boolean;
procedure Backend_Scan(aListBox: TListBox);
procedure Backend_Load_Existing(aListBox: TListBox);
implementation
const
opSave = 0;
opSaveConnect = 1;
opQueryConnect = 2;
opDeleteConnect = 3;
opConnectionConnect = 4;
opDisconnectActiveConnection = 5;
opScan = 6;
opLoadExisting = 7;
procedure Backend_Save(essid, pw: string);
begin
// backend opSave essid pw
end;
procedure Backend_Save_Connect(essid, pw: string);
begin
// backend opSaveConnect essid pw
end;
function Backend_Query_Connect(connection: string; var pw:string): boolean;
begin
// backend opQueryConnect essid pw
end;
function Backend_Delete_Connect(essid: string): boolean;
begin
// backend opDeleteConnect essid
result := true;
end;
function Backend_Connection_Connect(essid: string): boolean;
begin
// backend opConnectionConnect essid
end;
function Backend_Disconnect_Active_Connection: boolean;
begin
// backend opDisconnectActiveConnection
end;
procedure Backend_Scan(aListBox: TListBox);
begin
// backend opScan stringlist
end;
procedure Backend_Load_Existing(aListBox: TListBox);
begin
// backend opLoadExisting stringlist
end;
end.
-
On 17/08/2015, Edward Bartolo edb...@gmail.com wrote:
The Progress of My Coding Till Now:
I am attaching two images of the GUI's main window and the only
dialog. The GUI is programmed in Lazarus Pascal.
The backend is in C. The code till now, although it doesn't do anything
useful.
--
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
using namespace std;
#define opSave0
#define opSaveConnect 1
#define opQueryConnect2
#define opDeleteConnect 3
#define opConnectionConnect 4
#define opDisconnectActiveConnection 5
#define opScan6
#define opLoadExisting7
/*
1) Glib::spawn_sync instead of a pipe stream, provides a slot.
2) cmd trying to call an inexistent command still returns a valid pointer!
verify cmd exists before calling exec
*/
inline bool file_exists(char* name) {
return (access(name, F_OK) != -1);
}
int exec(const char* cmd, char* out)
{
const int buf_size = 128;
FILE * pipe = popen(cmd, r);
char buffer[buf_size];
while(!feof(pipe)) {
if(fgets(buffer, buf_size, pipe) != NULL)
{
if (out != NULL)
strcat(out, buffer);
else strcpy(out, buffer);
}
}
return pclose(pipe);
}
int main(int argc, char *argv[])
{
char *out = 0;
int switch_item = -1;
if (argc 1) switch_item = atoi(argv[1]);
switch (switch_item) {
case opSave:
//saveFile(argv[2], argv[3]);
exec(cat /etc/network/interfaces, out);
//out[0] = ' ';
printf(out);
return 0;
case opSaveConnect:
//saveFile(argv[2], argv[3]);
//Connect(argv[2]);
return 0;
case opQueryConnect:
return 0;
case opDeleteConnect:
break;
case opConnectionConnect:
break;
case opDisconnectActiveConnection:
break;
case opScan:
break;
case opLoadExisting:
return 0;
}
return -1; // parameter not in range
}
On 17/08/2015, Rainer Weikusat rainerweiku...@virginmedia.com wrote:
James Powell james4...@hotmail.com writes:
While there are packages that can be invisible and unintrusive into
the system, there are some that cannot.
The problem is
Re: [DNG] Systemd Shims
Systemd is not an option. Uselessd is an option, Runit is an option, s6 is an option, OpenRC is an option. Why, because any of these are init/supervisor sane replacements and/or extensions to sysvinit. When you replace the underlying system core with a completely alien hypervisor, you kill the option, and kill choice. Once systemd is in, it is in. -Jim From: T.J. Duchenemailto:t.j.duch...@gmail.com Sent: 8/15/2015 12:48 PM To: dng@lists.dyne.orgmailto:dng@lists.dyne.org Subject: Re: [DNG] Systemd Shims On Sat, 15 Aug 2015 03:15:50 -0700 James Powell james4...@hotmail.com wrote: Hi Jim! =) To me, a shim is not the way. Sanitization is what is needed, and if that requires work, then question this, 'Will the work be worth it?' and to me the answer is a definable 'yes'. I suppose there are some people like yourself who will always feel that way, and that is quite frankly - totally awesome. All that I ever try to say that I think there should be room for both sorts to make Devuan a home. Yes, I think Devuan should have systemd as an option, but only as an option - never part of the base system. Not to push a button, but I think Funtoo had the right mindset about systemd 'No way or chance in Hell'. I'm sorry Jim, but I see Funtoo as really a bad example of the situation. Funtoo is source based, and Devuan is not. They are both Linux but it is two very different worlds of users, like apples and oranges. It's a LOT easier to excise systemd when you are not expected to provide a binary. The minute you are expected to provide an official binary and have major features removed, users start to complain that your version is less than everyone else. Usually, the only ones who use source versions are power users and programmers who understand and accept the trade-offs in compiling your own OS. Have a great day! =) T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 16/08/2015 06:53, Steve Litt wrote: The toughest part is how to store the passwords in a way that isn't a security problem. Unfortunately, /etc/wpa_supplicant.conf doesn't have an include feature (which is strange, because hostapd supports a wpa_psk_file option). So you have to store the passwords (or the equivalent binary PSKs) in the configuration file, and make this file readable only from root - which means you need a small suid root binary to write the whole configuration file. Password security isn't a problem that you can fix at the interface level, it's something that must be tightly integrated with the tool that uses the password - and there's no doubt wpa_supplicant could do better here. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Hi, wondering what you all have been arguing about :) The systemd complex is vast and offers many attack vectors. Just do your thing. :) Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
I would like to humbly add my little contribution to this thread. I am posting using Devuan 64 bit connected to a home WIFI without any network managers. I connect by using separate /etc/network/interfaces files. The one for my home wifi is in /etc/network/interfaces while the rest are saved under my home directory. To connect, I use the command as root: ifup wlan0 -i an-interfaces-file My experience is this is a reliable connection. When I used wicd it used to disconnect very frequently. I also used desktop network managers, but these now many need systemd as a dependency. My point is, what I do manually, can be done through code resulting in a simple application. The advantage I see is, it would be standalone. I am tempted to create this application to automate my connection, but most probably, as I am more prolific in Delphi Pascal, the language of choice will be Lazarus Pascal. I can write C++ GUI applications but that requires more effort on my part. As long as logic programming in C/C++ that is on the same level if not easier. The hardest part seem to be allowing the ifup command to run with root privileges. On 16/08/2015, T.J. Duchene t.j.duch...@gmail.com wrote: Well, I suppose the topic has been beat up enough, but I just wanted to clear up something before moving on. I want you to understand why I came to the Devuan list in the first place. I came here under the assumption that Devuan was going to be a better Debian without the shove the Technical Committee and the failure of the GR gave to one single point of view. As far as I can tell, Devuan is about the same, with one difference. Devuan is willing to package systemd if it can be done cleanly - but nobody wants to. Debian will support System 5, again until nobody wants to. I suppose I should be used to that. The fault is mine. I expect too much, when everyone feels that they have been burned one too many times. Nexttime: Devuan will not work to support systemd and will not work against it. We will not do any effort to support it, if someone want to work to package it in a way where it works WITHOUT needs support for any other package depending on it, we will consider to add it as an option, but we will NOT accept it if it ask us to put it in dependency tree. That is all I EVER suggested, with one slight difference. That if it is somehow possible in the future to maintain two versions of the same package that the default version would be without systemd, but the other would be available at the users' option as a matter of choice. Steve Litt: Considering the source you're replying to, it's not worth even worrying about. The other side sure doesn't respect freedom of choice. That's why we're here in the first place. Inclusion of systemd tends to reduce freedom of choice, not enhance it. I am not on the other side of the argument. To me, there is no argument to begin with. I am neither an advocate for systemd nor am I an advocate for System 5. Both have issues and are basically different approaches to the same problem. That Steve objects to me personally - the source - is of course his own affair and I can care less. In saying this it is not a condemnation of him. I just do not want other people to think he knows what's on my mind. For the record, he doesn't even know me. Whatever his opinion of me, I respect his position just the same. Didier Kryn: This has been discussed so many times already! It sitll has to be proven that offering systemd is possible without abandoning freedom of choice for many other things. Honestly, Didier, I think it already has. Gentoo handles the situation very well. It is possible, but it might require some tweaking to get the packages right. Why should we bother when there's a simple way for Devuan to provide Systemd: http-redirect - www.debian.org I'm not accusing anyone of anything but I genuinely I do not understand that. Since the tone of Nexttime's post suggests that he/she would prefer that this discussion end, please message me privately if you have something to add. I don't understand how Devuan can grow if the general attitude on the mailing list is go away. Have a great day everyone! (Yes both Steve and Didlier too!) T. J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Well, I suppose the topic has been beat up enough, but I just wanted to clear up something before moving on. I want you to understand why I came to the Devuan list in the first place. I came here under the assumption that Devuan was going to be a better Debian without the shove the Technical Committee and the failure of the GR gave to one single point of view. As far as I can tell, Devuan is about the same, with one difference. Devuan is willing to package systemd if it can be done cleanly - but nobody wants to. Debian will support System 5, again until nobody wants to. I suppose I should be used to that. The fault is mine. I expect too much, when everyone feels that they have been burned one too many times. Nexttime: Devuan will not work to support systemd and will not work against it. We will not do any effort to support it, if someone want to work to package it in a way where it works WITHOUT needs support for any other package depending on it, we will consider to add it as an option, but we will NOT accept it if it ask us to put it in dependency tree. That is all I EVER suggested, with one slight difference. That if it is somehow possible in the future to maintain two versions of the same package that the default version would be without systemd, but the other would be available at the users' option as a matter of choice. Steve Litt: Considering the source you're replying to, it's not worth even worrying about. The other side sure doesn't respect freedom of choice. That's why we're here in the first place. Inclusion of systemd tends to reduce freedom of choice, not enhance it. I am not on the other side of the argument. To me, there is no argument to begin with. I am neither an advocate for systemd nor am I an advocate for System 5. Both have issues and are basically different approaches to the same problem. That Steve objects to me personally - the source - is of course his own affair and I can care less. In saying this it is not a condemnation of him. I just do not want other people to think he knows what's on my mind. For the record, he doesn't even know me. Whatever his opinion of me, I respect his position just the same. Didier Kryn: This has been discussed so many times already! It sitll has to be proven that offering systemd is possible without abandoning freedom of choice for many other things. Honestly, Didier, I think it already has. Gentoo handles the situation very well. It is possible, but it might require some tweaking to get the packages right. Why should we bother when there's a simple way for Devuan to provide Systemd: http-redirect - www.debian.org I'm not accusing anyone of anything but I genuinely I do not understand that. Since the tone of Nexttime's post suggests that he/she would prefer that this discussion end, please message me privately if you have something to add. I don't understand how Devuan can grow if the general attitude on the mailing list is go away. Have a great day everyone! (Yes both Steve and Didlier too!) T. J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
While there are packages that can be invisible and unintrusive into the system, there are some that cannot. The problem is responsibility. Who wants to remain responsible for boot scripts? Upstream or vendor? Who wants responsibility for providing interoperability between projects? Upstream or downstream bazaar? Who wants responsibility for the userland? Upstream or the downstream bazaar? To me, this 'lack of' responsibility, and honestly this isn't just aimed at systemd, but as modern society as a whole, is the cause of this mess. This lack of personal and public responsibility has led to the rise of things like this, and it's high time we stand up and say either 'start being responsible' or 'take responsibility' or else? Or else what? You'll find out when all the pushed off responsibility you didn't want comes crashing back down on you. Didn't want to get political, philosophical, or religious, but sometimes enough is enough. -Jim From: Franco Lanzamailto:next...@nexlab.it Sent: 8/16/2015 1:46 PM To: dng@lists.dyne.orgmailto:dng@lists.dyne.org Subject: Re: [DNG] Systemd Shims On Sun, Aug 16, 2015 at 12:13:04PM -0500, T.J. Duchene wrote: Well, I suppose the topic has been beat up enough, but I just wanted to clear up something before moving on. I want you to understand why I came to the Devuan list in the first place. I came here under the assumption that Devuan was going to be a better Debian without the shove the Technical Committee and the failure of the GR gave to one single point of view. Well, we are here also to try to build up a better debian without single point of view, yes, and to avoid single point of view for the future, we are trying to move from TC imposed view to VUA imposed policy. What's the difference? With a TC imposed view like in debian, you can't assume any decision before the decision is made. With a VUA imposed policy, when the policy will be complete and public, it isn't yet, you can know how anything will be managed in future. Basically, more power to our constitution and less to people in charge, where people in charge will just act as constitution custodes. As far as I can tell, Devuan is about the same, with one difference. Devuan is willing to package systemd if it can be done cleanly - but nobody wants to. Debian will support System 5, again until nobody wants to. No, it isn't like this. It's this way: Debian will support sysv, until nobody wants to. Devuan will support anything that is feasible to do without ruining all other options and impose one single way to do that, assuming someone will accept to do the work. The Devuan way is a policy, not something against a specific software. Sadly systemd apply for this limitation as it can't be done without hijacking whole system and imposing one way, so, it can't be an option in my opinion. If anyone will get the work done and make it usable without hijacking whole base system, well, Devuan will embrace it as an option like anything else. Pratically, to me, this seems to be impossible. Nexttime: Devuan will not work to support systemd and will not work against it. We will not do any effort to support it, if someone want to work to package it in a way where it works WITHOUT needs support for any other package depending on it, we will consider to add it as an option, but we will NOT accept it if it ask us to put it in dependency tree. That is all I EVER suggested, with one slight difference. That if it is somehow possible in the future to maintain two versions of the same package that the default version would be without systemd, but the other would be available at the users' option as a matter of choice. This is of course feasible, yes. BUT how many packages will need two versions? For systemd, too many, this is a way we can use for few packages, but using it for 1 packages is probably a too huge effort, at least for the moment. In future, who knows. NOTE: my nickname is nextime, with 1 single t. Is isn't derived from next-time, it comes from the software called nextime that was in some wat the grandfather of the now called quicktime when it was born on NextOS. -- Franco (nextime) Lanza Lonate Pozzolo (VA) - Italy SIP://c...@casa.nexlab.it web: http://www.nexlab.net NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng
Re: [DNG] Systemd Shims
Hello James, On 08/17/2015 02:28 AM, James Powell wrote: While there are packages that can be invisible and unintrusive into the system, there are some that cannot. The problem is responsibility. Who wants to remain responsible for boot scripts? Upstream or vendor? Who (developer, vendor, user) *could* remain responsible if no distribution offered the possibility to run a service off a boot script anymore, and all made systemd mandatory instead? So, in order to provide freedom of choice to both developers and users, the primary task is to provide environments were different init systems are possible at all. How to utilize a specific init system to support a specific software providing a specific service is a specific task (that not neccessarily involves boot scripts at all, I still try to figure out what service actually means). Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sun, 16 Aug 2015 18:48:44 +0100 Edward Bartolo edb...@gmail.com wrote: I would like to humbly add my little contribution to this thread. I am posting using Devuan 64 bit connected to a home WIFI without any network managers. I connect by using separate /etc/network/interfaces files. The one for my home wifi is in /etc/network/interfaces while the rest are saved under my home directory. To connect, I use the command as root: ifup wlan0 -i an-interfaces-file I, too, am a big fan of command based network connections rather than data based. My only question is this: What is life like when you walk from Macdonalds to Burger King and change hotspots? I think for the travelling guy, there must be a quick facility to see available hotspots with their strengths and security status, choose one, input a password if that ESSID hasn't been encountered already, and log in. What was in your an-interfaces-file? (obviously change the passwords). Did you use wpa-supplicant at all? [snip] My point is, what I do manually, can be done through code resulting in a simple application. The advantage I see is, it would be standalone. Pre-cisely! I am tempted to create this application to automate my connection, but most probably, as I am more prolific in Delphi Pascal, the language of choice will be Lazarus Pascal. I can write C++ GUI applications but that requires more effort on my part. As long as logic programming in C/C++ that is on the same level if not easier. Show me the way you do it manually, and I'll make something into which you can plug in your Lazarus front end. Somebody else can plug in their Dialog front end. The hardest part seem to be allowing the ifup command to run with root privileges. Well, if the user doesn't mind having sudo with a sudoers file, easiest way to do that is to allow sudo nopassword. Is there a non-root group that would allow ifup to do its thing? What does your ifup command look like, and what does the an-interfaces-file look like? Does one interfaces file contain lots of ESSIDs, or one ESSID per interface file? What do you do about making the password secure from prying, non-root eyes? As far as you know, do you use wpa_supplicant in any way? Thanks, SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Forget about the CLI program or daemon. I can create a window with the following features. Then, we can decide about the backends. We can avoid having a full fledged sudo setup by ONLY allowing the few backends to work with it. This should help securitywise. Propose GUI: Main window with: a) listing the available wifi hotspots and the following buttons: New, Delete and Edit b) popup dialog asking for ESSID and password What do you think? I am waiting your go ahaid. If you tell me to begin, tomorrow it will be ready. Waiting for your orders... :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Alternatively, instead of running the ifup command with sudo, one can start the application/daemon itself using sudo. This makes it possible to use sudo while allowing only our application/daemon to run with root privileges. I also think, this application can be made into a daemon and started by a sysvinit script. However, let us not run, first we learn to walk by providing a way to connect in a desktop or window manager. I think, there is no need of providing a graphical dialog for users as a shell can be made to automatically open asking for the ESSID and password interactively. I think, I can start working on this, as this seems to be possible. On 16/08/2015, Edward Bartolo edb...@gmail.com wrote: I think, there is no need of providing a graphical dialog for users as a shell can be made to automatically open asking for the ESSID and password interactively. I think, I can start working on this, as this seems to be possible. On 16/08/2015, Edward Bartolo edb...@gmail.com wrote: Alternatively, instead of running the ifup command with sudo, one can start the application/daemon itself using sudo. This makes it possible to use sudo while allowing only our application/daemon to run with root privileges. I also think, this application can be made into a daemon and started by a sysvinit script. However, let us not run, first we learn to walk by providing a way to connect in a desktop or window manager. On 16/08/2015, Edward Bartolo edb...@gmail.com wrote: The ifup command is the one that comes ready with a default installation. The contents of an-interfaces-file is as follows. Be advised that eth0 may not be needed in our case, but I included it to be on the safe side. - # The loopback network interface auto lo iface lo inet loopback # The primary network interface # allow-hotplug eth0 iface eth0 inet dhcp # WIFI Configuration # auto wlan0 iface wlan0 inet dhcp wpa-ssid wifinamestring wpa-psk password - I create one interfaces file per wifi point and keep them in a different location. Then, I use the command: ifup wlan0 -i specific-interface-file I have wpasupplicant installed and the wifi itself is configured only for encrypted connections. The variour interfaces files are made unreadable by non root users by changing ownership and permissions. In the past I used sudo to only allow a custom script be run by non root. To disallow non root from using ifup with its full flexibility I created a script which took no parameters to specifically run the ifup command complete with the parameter list I wanted. Other than ifup was not allowed to be run by non root. I think, the algorithm may work something on these lines: 1) query for a list of available ESSIDs 2) sort for the one with the strongest signal 3) check whether there is an interfaces file with that ESSID ... i) if found call ifup using the file, check return value from ifup a) if success exit and continue b) if failed try with the next signal strength ii) if an intefaces file does not exist present a dialog with the ESSID if available, ask for ESSID and password, goto i) The files I create are all like the one I quoted. To connect, I run ifup as root as follows: ifup -i interfaces-file-for-wifi-point wlan0 That's all. Thanks On 16/08/2015, Steve Litt sl...@troubleshooters.com wrote: On Sun, 16 Aug 2015 18:48:44 +0100 Edward Bartolo edb...@gmail.com wrote: I would like to humbly add my little contribution to this thread. I am posting using Devuan 64 bit connected to a home WIFI without any network managers. I connect by using separate /etc/network/interfaces files. The one for my home wifi is in /etc/network/interfaces while the rest are saved under my home directory. To connect, I use the command as root: ifup wlan0 -i an-interfaces-file I, too, am a big fan of command based network connections rather than data based. My only question is this: What is life like when you walk from Macdonalds to Burger King and change hotspots? I think for the travelling guy, there must be a quick facility to see available hotspots with their strengths and security status, choose one, input a password if that ESSID hasn't been encountered already, and log in. What was in your an-interfaces-file? (obviously change the passwords). Did you use wpa-supplicant at all? [snip] My point is, what I do manually, can be done through code resulting in a simple application. The advantage I see is, it would be standalone. Pre-cisely! I am tempted to create this application to automate my connection, but most probably, as I am more prolific in Delphi Pascal, the language of choice will be Lazarus Pascal. I can write C++ GUI applications but that requires more effort on my
Re: [DNG] Systemd Shims
The backends can be integrated into one single executable not to clutter the sudoers file and to increase system efficiency. I propose to place the other interface file in: /etc/network/interfaces/wifi I can start the implementation of the GUI (Lazarus Pascal) and the backend (C++), but I need your opinion first. Edward On 17/08/2015, Edward Bartolo edb...@gmail.com wrote: Forget about the CLI program or daemon. I can create a window with the following features. Then, we can decide about the backends. We can avoid having a full fledged sudo setup by ONLY allowing the few backends to work with it. This should help securitywise. Propose GUI: Main window with: a) listing the available wifi hotspots and the following buttons: New, Delete and Edit b) popup dialog asking for ESSID and password What do you think? I am waiting your go ahaid. If you tell me to begin, tomorrow it will be ready. Waiting for your orders... :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
I would be interested in * No-dbus replacement for NetworkManager/Wicd Are you thinking a C program? HECK no! There's no requirement for this program to be fast, and I want to make it easy on myself. Python probably, with the minimum Python addons, and only addons that ship with Python itself. If people really hate the Python dependency (I thought almost everyone installs Python anyway), perhaps I could make it out of shellscripts, awk and the like. I too am interested in a no-dbus replacement for NetworkManager/Wicd I also like the idea of a shell script, it would make it more accessible to more people, but only if it is feasible. A thing should be as simple as possible but no simpler. So if it needs perl or python then so be it, it would not be the first tool with such a dependency. But my preference would be shell. Regards, /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sun, 16 Aug 2015 14:26:41 +1200 Daniel Reurich dan...@centurion.net.nz wrote: On 16 August 2015 7:47:46 AM GMT+12:00, T.J. Duchene t.j.duch...@gmail.com wrote: All that I ever try to say that I think there should be room for both sorts to make Devuan a home. Yes, I think Devuan should have systemd as an option, but only as an option - never part of the base system. No no no! If you Devuan with systemd install Debian. I agree. Daniel, I don't know why it's so hard for some people to understand. We're all for freedom of choice, but catering to this mythical Devuan user who wants systemd reduces *our* choices by making it much harder to (I've been told not to use the neologism), ummm, decontaminate Devuan. Considering the source you're replying to, it's not worth even worrying about. The other side sure doesn't respect freedom of choice. That's why we're here in the first place. Inclusion of systemd tends to reduce freedom of choice, not enhance it. I will not continue to work on Devuan if it means compromising it for the systemd fan boys who want to infect Devuan with Lennarts and Co's crap. If we could permanently remove avahi and pulseaudio then all the better. I can't blame you a bit, but don't stop because of the guy to whom you're replying. If you want systemd with your linux, your in the wrong forum and looking at the wrong distrobution. A-friggin-men, and that's why I long ago piped his messages to /dev/null. And yet, apparently, months later, he's still advocating bringing systemd into Devuan. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sun, 16 Aug 2015 07:37:16 +0300 Lars Noodén lars.noo...@gmail.com wrote: I would be interested in * No-dbus replacement for NetworkManager/Wicd Are you thinking a C program? HECK no! There's no requirement for this program to be fast, and I want to make it easy on myself. Python probably, with the minimum Python addons, and only addons that ship with Python itself. If people really hate the Python dependency (I thought almost everyone installs Python anyway), perhaps I could make it out of shellscripts, awk and the like. I too am interested in a no-dbus replacement for NetworkManager/Wicd I also like the idea of a shell script, it would make it more accessible to more people, but only if it is feasible. A thing should be as simple as possible but no simpler. So if it needs perl or python then so be it, it would not be the first tool with such a dependency. But my preference would be shell. Regards, /Lars You might be in luck, if a few more people jump in. One person emailed me offlist with code to do this, either we could all start using his code, or I could use his code as a starting point. The toughest part is how to store the passwords in a way that isn't a security problem. But then again, with NetworkManager, as I remember, you can click clear text and see the passwords :-) SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Le 15/08/2015 18:01, Steve Litt a écrit : On Sat, 15 Aug 2015 08:51:55 +0200 Didier Kryn k...@in2p3.fr wrote: Le 15/08/2015 02:26, Steve Litt a écrit : On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. In the massive time I save as not being the bomb squad defusing Red Hat's terrorism, I'd write small replacements for a lot of things that use only Linux and a very rudimentary and optional GUI interface. Then I'd write documentation explaining how to use a sharp thinking computer, to the proud ignorants of the world, especially those who believe their ignorance is a badge of honor proving their age or gender. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. You don't want me in that capacity. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) SteveT Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier OK. What should come first? * Automounter? * No-dbus replacement for NetworkManager/Wicd? * Other? Please keep in mind, I'm not a good enough programmer to write a substitute for Gimp or Gnome. Let's keep the first one simple and easy so I can actually do it, in a reasonable timeframe, without adversely impacting my real work. Well you seem to have a lot of ideas and recipes and a good experience of not well known simple and smart tools. I got just two ideas of things you already discussed: Do you think a mount helper would be achievable with dmenu? I know you and some other people prefer an automounter, and may be it could be a first step before the mount helper. A light replacement for wpagui/wicd would be nice. Interfacing directly with wpa_supplicant requires probably a lot of technical knowledge about wifi protocols. But maybe it is simpler when interfacing through wpacli - let's not re-invent the wheel. I know we have all shaked ideas about all this but it does not prove that it is easy. What I mean is if you make something smart and usefull for you, people will love to try it because many here are tuned on the same frequency as you, KISS and smart. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
I would be interested in * No-dbus replacement for NetworkManager/Wicd Are you thinking a C program? daemon and user interface/GUI separation? On 2015-08-15 18:01, Steve Litt wrote: On Sat, 15 Aug 2015 08:51:55 +0200 Didier Kryn k...@in2p3.fr wrote: Le 15/08/2015 02:26, Steve Litt a écrit : On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. In the massive time I save as not being the bomb squad defusing Red Hat's terrorism, I'd write small replacements for a lot of things that use only Linux and a very rudimentary and optional GUI interface. Then I'd write documentation explaining how to use a sharp thinking computer, to the proud ignorants of the world, especially those who believe their ignorance is a badge of honor proving their age or gender. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. You don't want me in that capacity. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) SteveT Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier OK. What should come first? * Automounter? * No-dbus replacement for NetworkManager/Wicd? * Other? Please keep in mind, I'm not a good enough programmer to write a substitute for Gimp or Gnome. Let's keep the first one simple and easy so I can actually do it, in a reasonable timeframe, without adversely impacting my real work. Thanks, SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Simon Hobson li...@thehobsons.co.uk writes: T.J. Duchene t.j.duch...@gmail.com wrote: I used Debian Sid recently, with the apparent ability to boot using either System 5 or Systemd via Grub. The choice seems clear to me that Devuan could minimize upsteam maintenance by looking at that. The problem is not which init system to use - SystemD is not just an init system. Even if you use Sys5 init, there are a lot of packages that require parts of SystemD to install/work - so being able to boot with Sys5 init is a bit of a red herring really. As recently demonstrated, dealing with such situations one-by-one isn't really a problem: You (or anyone else) could use the patch I posted to compile a systemd-free clamav package for Jessie and share the results for distribution. In case it doesn't address the issue completely enough from a practical point, I could very likely help with getting it to this point (within some reasonable time limits, obviously). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sun, 16 Aug 2015 00:08:11 +0200 shraptor shrap...@bahnhof.se wrote: On 2015-08-15 18:01, Steve Litt wrote: Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier OK. What should come first? * Automounter? * No-dbus replacement for NetworkManager/Wicd? * Other? Please keep in mind, I'm not a good enough programmer to write a substitute for Gimp or Gnome. Let's keep the first one simple and easy so I can actually do it, in a reasonable timeframe, without adversely impacting my real work. I would be interested in * No-dbus replacement for NetworkManager/Wicd Are you thinking a C program? HECK no! There's no requirement for this program to be fast, and I want to make it easy on myself. Python probably, with the minimum Python addons, and only addons that ship with Python itself. If people really hate the Python dependency (I thought almost everyone installs Python anyway), perhaps I could make it out of shellscripts, awk and the like. daemon and user interface/GUI separation? I'm not sure whether an actual daemon would be needed, but either way, the user interface would be a separate program from the thing that reveals the wifi transmitters, deals with wpa-supplicant and iwlist, etc. I'd probably make one curses interface, and one GUI. I *might* even do them with dialog and zenity. But I'd need *a lot* more people wanting it to do it. The way Devuan does Wicd right now means making this program isn't personally urgent. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 16 August 2015 7:47:46 AM GMT+12:00, T.J. Duchene t.j.duch...@gmail.com wrote: On Sat, 15 Aug 2015 03:15:50 -0700 James Powell james4...@hotmail.com wrote: Hi Jim! =) To me, a shim is not the way. Sanitization is what is needed, and if that requires work, then question this, 'Will the work be worth it?' and to me the answer is a definable 'yes'. I suppose there are some people like yourself who will always feel that way, and that is quite frankly - totally awesome. All that I ever try to say that I think there should be room for both sorts to make Devuan a home. Yes, I think Devuan should have systemd as an option, but only as an option - never part of the base system. No no no! If you Devuan with systemd install Debian. I will not continue to work on Devuan if it means compromising it for the systemd fan boys who want to infect Devuan with Lennarts and Co's crap. If we could permanently remove avahi and pulseaudio then all the better. If you want systemd with your linux, your in the wrong forum and looking at the wrong distrobution. Daniel ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
My $0.02... Shims are not needed, or, in my viewpoint, wanted. You're still working with systemd or pseudo-systemd and either way you see it, it's still systemd. While the prospect of systemd-shim does allow to separate the API layer and logind out from the core project, as uselessd allowed the systemd-init to be separated out, it's still working with systemd, and systemd is still required to build it, the shim, from source. The only shim that doesn't require systemd is loginkit and that project hasn't really done much, no offensive meant. To me, a shim is not the way. Sanitization is what is needed, and if that requires work, then question this, 'Will the work be worth it?' and to me the answer is a definable 'yes'. If this is going to be System V based GNU/Linux, then why is there talk of systemd? System V GNU/Linux is not systemd GNU/Linux. Not to push a button, but I think Funtoo had the right mindset about systemd 'No way or chance in Hell'. -Jim From: Didier Krynmailto:k...@in2p3.fr Sent: 8/14/2015 11:52 PM To: dng@lists.dyne.orgmailto:dng@lists.dyne.org Subject: Re: [DNG] Systemd Shims Le 15/08/2015 02:26, Steve Litt a écrit : On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. In the massive time I save as not being the bomb squad defusing Red Hat's terrorism, I'd write small replacements for a lot of things that use only Linux and a very rudimentary and optional GUI interface. Then I'd write documentation explaining how to use a sharp thinking computer, to the proud ignorants of the world, especially those who believe their ignorance is a badge of honor proving their age or gender. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. You don't want me in that capacity. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) SteveT Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Le 15/08/2015 02:26, Steve Litt a écrit : On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. In the massive time I save as not being the bomb squad defusing Red Hat's terrorism, I'd write small replacements for a lot of things that use only Linux and a very rudimentary and optional GUI interface. Then I'd write documentation explaining how to use a sharp thinking computer, to the proud ignorants of the world, especially those who believe their ignorance is a badge of honor proving their age or gender. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. You don't want me in that capacity. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) SteveT Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sat, 15 Aug 2015 12:01:35 -0400 Steve Litt sl...@troubleshooters.com wrote: Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier OK. What should come first? * Automounter? * No-dbus replacement for NetworkManager/Wicd? * Other? Please keep in mind, I'm not a good enough programmer to write a substitute for Gimp or Gnome. Let's keep the first one simple and easy so I can actually do it, in a reasonable timeframe, without adversely impacting my real work. I think what can be done has been done as far as Devuan 1.0 and there is no reason to be overly zealous about the issue of systemd. Conversely, it is the future that concerns me. I think that in the interests of user choice and to ease upstream maintenance from Debian and eventually from projects like Gnome some form of accommodation for systemd will have to be made. I used Debian Sid recently, with the apparent ability to boot using either System 5 or Systemd via Grub. The choice seems clear to me that Devuan could minimize upsteam maintenance by looking at that. If it is truly a System 5 boot, a lot of problems could be eased by simply making System 5 boot the default in Grub, and then leaving the choice up to the user. I suspect that the Sid install I was using had systemd-shim installed in order to handle certain packages. I'm sorry to say that I did not verify this. My time was limited. I had to move on and install something else. Even if it was systemd-shim, what if Devuan simply cloned Debian, used System 5 + systemd-shim as the default? As a supplement, Devuan could add a set of alternative packages to replace systemd ones in post-release. I know that would be distasteful to some, but it would be the easiest route with a small team, limited resources, and it would give the Devuan time more breathing room and time to do things. It would preserve user choice and not force Devuan to drop packages that it does not have the developers to fork. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, 8/14/15, Steve Litt sl...@troubleshooters.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 7:26 PM On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. Whoa! I suggested putting you in charge of decontaminating packages not deciding inclusion/exclusion policy! Actually the suggestion was more to pull your chain than anything else (and it worked didn't it). You're quite entertaining when you get wound up. :) golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Simon Hobson li...@thehobsons.co.uk writes: Rainer Weikusat rainerweiku...@virginmedia.com wrote: ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS, Slackware and Windows, all of which certainly don't have systemd. I've just cloned the current development repository and build it on Wheezy using a plain ./configure make which worked without issues and this system is certainly systemd-free, too. Which makes it even more non-sensical to make it have systemd dependencies. Could perhaps provide some kind of link illustrating what you were referring to? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789283 And from http://lists.clamav.net/pipermail/clamav-users/2015-June/001604.html BTW, since I'm the primary clamav maintainer in Debian, guess how much action your report is going to get. As you've pointed out, this is a package widely used across various OSs, and is still officially supported in Wheezy through security updates. But the Debian Jessie package hard depends on libsystemd0. Since that's basically a requirement one of Debian guys gratuitiously added and the package actually supports building without systemd, just not for Debian 8 onwards, it's easy to get rid of it: - diff -rNu clamav-0.98.7+dfsg/debian/clamav-daemon.install clamp/debian/clamav-daemon.install --- clamav-0.98.7+dfsg/debian/clamav-daemon.install 2015-05-02 03:48:31.0 +0100 +++ clamp/debian/clamav-daemon.install 2015-08-15 16:53:27.732670081 +0100 @@ -1,6 +1,4 @@ debian/script usr/share/bug/clamav-daemon/ -debian/tmp/lib/systemd/system/clamav-daemon.service -debian/tmp/lib/systemd/system/clamav-daemon.socket debian/tmp/usr/bin/clamconf debian/tmp/usr/bin/clamdtop debian/tmp/usr/sbin/clamd diff -rNu clamav-0.98.7+dfsg/debian/clamav-freshclam.install clamp/debian/clamav-freshclam.install --- clamav-0.98.7+dfsg/debian/clamav-freshclam.install 2015-05-02 03:48:31.0 +0100 +++ clamp/debian/clamav-freshclam.install 2015-08-15 16:53:11.237179310 +0100 @@ -3,6 +3,5 @@ debian/clamav-freshclam-ifupdown etc/ppp/ip-down.d/ debian/clamav-freshclam-ifupdown etc/ppp/ip-up.d/ debian/script usr/share/bug/clamav-freshclam/ -debian/tmp/lib/systemd/system/clamav-freshclam.service debian/tmp/usr/bin/freshclam debian/usr.bin.freshclam etc/apparmor.d/ diff -rNu clamav-0.98.7+dfsg/debian/rules clamp/debian/rules --- clamav-0.98.7+dfsg/debian/rules 2015-05-03 02:57:42.0 +0100 +++ clamp/debian/rules 2015-08-15 16:54:28.970779493 +0100 @@ -48,7 +48,6 @@ --disable-clamav --disable-unrar --enable-milter --enable-dns-fix \ --with-libjson \ --with-gnu-ld $(SYSTEM_LLVM) \ - --with-systemdsystemunitdir=/lib/systemd/system DEBUG_OPTS= @@ -60,20 +59,19 @@ endif # The autotools in squeeze (Debian 6) are too old, so don't use autoreconf. -# And don't use systemd. ifeq ($(shell cut -c1 /etc/debian_version),6) AUTORECONF = - SYSTEMD = else ifeq ($(shell cut -c1 /etc/debian_version),7) AUTORECONF = --with autoreconf - SYSTEMD = else AUTORECONF = --with autoreconf - SYSTEMD = --with systemd endif endif +# don't use systemd +SYSTEMD = + # Use the default debhelper scripts, where possible. # Enable parallel building and conditionally autoreconf and systemd. %: - The patch is supposed to be applied to the unpacked Debian source package. Without the changes to the install files, the package apparently can't be build on wheezy at all, at least, it failed for me. I've tested that it builds on wheezy with these changes. BTW, one of the reasons why I'll try to stay clear of systemd is because I won't ever voluntarily trust people who employ this aggressive jerk in a position of power communication style in order to (man-)'handle' individuals with dissenting opinions: This is not only unpleasant but also deeply irrational. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sat, 15 Aug 2015 08:51:55 +0200 Didier Kryn k...@in2p3.fr wrote: Le 15/08/2015 02:26, Steve Litt a écrit : On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. In the massive time I save as not being the bomb squad defusing Red Hat's terrorism, I'd write small replacements for a lot of things that use only Linux and a very rudimentary and optional GUI interface. Then I'd write documentation explaining how to use a sharp thinking computer, to the proud ignorants of the world, especially those who believe their ignorance is a badge of honor proving their age or gender. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. You don't want me in that capacity. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) SteveT Please, Steve, provide us with all you mentionned, as an alternative to mainstream bloated/infected stuff. Since Devuan is all about freedom, this is the place where to deliver to the world. As soon as I can install Devuan on metal, I'll be one of your testers. Didier OK. What should come first? * Automounter? * No-dbus replacement for NetworkManager/Wicd? * Other? Please keep in mind, I'm not a good enough programmer to write a substitute for Gimp or Gnome. Let's keep the first one simple and easy so I can actually do it, in a reasonable timeframe, without adversely impacting my real work. Thanks, SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
T.J. Duchene t.j.duch...@gmail.com wrote: I used Debian Sid recently, with the apparent ability to boot using either System 5 or Systemd via Grub. The choice seems clear to me that Devuan could minimize upsteam maintenance by looking at that. The problem is not which init system to use - SystemD is not just an init system. Even if you use Sys5 init, there are a lot of packages that require parts of SystemD to install/work - so being able to boot with Sys5 init is a bit of a red herring really. On 15 Aug 2015, at 01:26, Steve Litt sl...@troubleshooters.com wrote: Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. Which really leads on to one of the hard choices facing Devuan. If you don't have the packages people need to run, then they can't run Devuan. And if those needed packages have been modified to need SystemD then it needs work to re-convert them. I guess a look at Debian PopCon might give some ideas which packages are being used - and hence where to spend limited dev resources. Though I suppose you could decide to ignore the GUI packages to stat with - there's a large user base (like myself) who run headless servers and so really don't care about any of the packages in that list ! Long term, you could try and get the GUI stuff in - but I suspect that's going to get harder and harder over time as the Japanese Knotweed of the software world gets a deeper hold. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
If anything, shims for systemd should be something that relies on LD_PRELOAD to provide the wrappers, rather than making them broadly available - so that it's possible to use it as a workaround, but without deliberately doing so, the affected packages WILL break. I fear however that we're going to see packages with deeper and deeper entanglement with systemd, where it won't be a simple matter to patch the software to work correctly. Gnome already seems to be moving full speed ahead in this direction, and unfortunately, it's a matter of time before others follow suit. Since systemd is firmly committed to being Linux only, other *nix operating systems, including the *BSD world are having to build workarounds. I think collaboration with them on a common implementation that provides a workable, portable, and non-invasive comparability layer would be mutually beneficial, and needn't be exclusive of efforts to disentangle packages from the systemd beast altogether. On Fri, Aug 14, 2015 at 8:59 AM Simon Hobson li...@thehobsons.co.uk wrote: It seems to me that it's good to have shim programs that satisfy dependencies of apps on systemd, each shim performing some systemd function. Here's why: Suppose there are 10,000 application programs (apps) for Linux, and their developers foolishly insert dependencies on systemd. If Devuan developers write 50 simple shims to fulfill those dependencies, then Devuan users can run those 10,000 apps as they are, directly from the Debian repos. And when the apps are updated, they will still run. As pointed out already, unless the systemd calls are not actually doing anything useful to the operation of the program then replacing each call with a null operation will break the program. But, IMO there is a more important philosophical reason not to do it. If it were technically possible to create all these shims that would do nothing but magically still let programs work, by doing it that way you have legitimised the use of those systemd calls. As in, use as many as you like, it doesn't actually matter. If Devuan can get to the point where the devs that are blindly going down the systemd alley* want to get on board, without these shims there is a clear message - fix your code or it can't be installed. * I'm sure some feel they are using systemd calls for a good reason. In many cases there may well be merit in using them when available. As an example, I tried to upgrade one of my Wheezy systems to Jessie with *systemd* pinned as not installable. It took a bit of messing around figuring out what the broken dependencies were, and in the end I only had ONE single package that I needed and which wouldn't install - clamav-daemon (the other clamav* packages were fine, just not that individual one). In response to my messages on the clamav mailing list and bug report, it turns out that they only make ONE call to libsystemd during startup and then never use it again, and it's not even an essential call - but no, it would be a waste of CPU cycles to do a if exists libsystemd0 then call ... I assume it's not considered a waste of cycles to maintain a separate package for Wheezy security updates ! If you provide a shim, then you legitimise this sort of behaviour. Which would you prefer : a clamav-daemon package with a dependency on a fake libsystemd0, or a clamav-daemon package without any systemd dependency ? If you legitimise using shims, then the same people that see no reason to not hard-depend on libsystemd0 will bring you a package with a hard-depends on fake-libsystemd0. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Hi Stephanie! =) On Fri, 14 Aug 2015 13:44:42 + Stephanie Daugherty sdaughe...@gmail.com wrote: I fear however that we're going to see packages with deeper and deeper entanglement with systemd, where it won't be a simple matter to patch the software to work correctly. Gnome already seems to be moving full speed ahead in this direction, and unfortunately, it's a matter of time before others follow suit. It's already a done deal. KDE announced that they are going to soft-depend on systemd. =P I really so not see what the big deal about a shim is, and why we even debating the idea. It is just a compatibility wrapper, no more or less evil than any other. BSD already does that for some software because Linux has basically taken over. Yes, systemd is Linux specific and I prefer POSIX, but there is no official spec in POSIX for init, so I can't fault anyone for using systemd. Systemd is not particularly good for servers and so I agree with Devuan that it needs to remain optional, but neither is it a pressing problem that is going to end the world. I prefer to stick with the engineering facts, and not hyperbole. There are three and only three ways to end the systemd/Linux only problem. One is to force the Linux community to stop using Linux only system calls. That is *NOT* going to happen. The other is to provide a layer to mitigate those calls. That is exactly what a shim does. The third is to fork every software that depends on systemd or drop support for it entirely. What Devuan does on that is up to them, but I would suggest that a Devuan without software is less useful than one that uses a shim. I do not think they are going to have the resources to maintain an ever-increasing number of forks. I think collaboration with them on a common implementation that provides a workable, portable, and non-invasive comparability layer would be mutually beneficial, and needn't be exclusive of efforts to disentangle packages from the systemd beast altogether. Personally, I agree with you. I see the shim as the only reasonable option going forward at present, unless things change within the community radically. It's the only one that makes engineering sense. FreeBSD also thinks the same way, They are presently working on a shim to mitigate the issue of systemd. I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. If it is of any interest, the last time I tested Debian Sid a few days ago, it had the option on the Grub menu to choose to boot via System 5 or Systemd. Have a fabulous day! T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, Aug 14, 2015 at 01:59:32PM +0100, Simon Hobson wrote: As an example, I tried to upgrade one of my Wheezy systems to Jessie with *systemd* pinned as not installable. It took a bit of messing around figuring out what the broken dependencies were, and in the end I only had ONE single package that I needed and which wouldn't install - clamav-daemon (the other clamav* packages were fine, just not that individual one). In response to my messages on the clamav mailing list and bug report, it turns out that they only make ONE call to libsystemd during startup and then never use it again, and it's not even an essential call - but no, it would be a waste of CPU cycles to do a if exists libsystemd0 then call ... I assume it's not considered a waste of cycles to maintain a separate package for Wheezy security updates ! Good evening, It's true, that's a waste, although very small, to add an if structure. Remains a weak argument: not being clamav a Go project, it has for sure a badly optimized, on the buiding side, codebase, so a config macro and an #ifdef SYSTEMD_EXISTS around the call surely doesn't waste anything valuable. -- Teodoro Santoni Something is wrong. I don't wanna compile 20 KB of Go code to list files. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, 14 Aug 2015 13:59:32 +0100 Simon Hobson li...@thehobsons.co.uk wrote: If Devuan developers write 50 simple shims to fulfill those dependencies, then Devuan users can run those 10,000 apps as they are, directly from the Debian repos. And when the apps are updated, they will still run. As pointed out already, unless the systemd calls are not actually doing anything useful to the operation of the program then replacing each call with a null operation will break the program. But, IMO there is a more important philosophical reason not to do it. If it were technically possible to create all these shims that would do nothing but magically still let programs work, by doing it that way you have legitimised the use of those systemd calls. As in, use as many as you like, it doesn't actually matter. If Devuan can get to the point where the devs that are blindly going down the systemd alley* want to get on board, without these shims there is a clear message - fix your code or it can't be installed. Laurent Bercot earlier brought up this exact philosophical reason not to do it. You two make a good point, but I disagree with the point. This point would be spot on if Devuan had any marketplace clout. The trouble is, with Devuan currently having such a tiny market share, and Devuan having almost zero funding (compared to Red Hat, Cannonical, SuSE), threaten an upstream with your software won't go on Devuan and their response will be so what, I'll lose 0.1% of my users. In fact, compared to that tiny loss, Devuan will lose many more because many user's favorite program won't run on Devuan, for philosophical reasons. Which makes it yet harder for users to avoid systemd, creating more systemd usership, shrinking our market share even more. Bottom line: The perfect is the enemy of the good. To the extent that shims can defuse silly, reasonless dependencies, in situations where a revised makefile and maybe tiny changes to the C can't do it, shims help Devuan continue to promote life without systemd, and hasten the day when *everybody* will realize King Lennart has no clothes. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, 14 Aug 2015 14:49:17 -0700 Go Linux goli...@yahoo.com wrote: On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all systemd on us. In the massive time I save as not being the bomb squad defusing Red Hat's terrorism, I'd write small replacements for a lot of things that use only Linux and a very rudimentary and optional GUI interface. Then I'd write documentation explaining how to use a sharp thinking computer, to the proud ignorants of the world, especially those who believe their ignorance is a badge of honor proving their age or gender. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. You don't want me in that capacity. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Rainer Weikusat rainerweiku...@virginmedia.com wrote: ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS, Slackware and Windows, all of which certainly don't have systemd. I've just cloned the current development repository and build it on Wheezy using a plain ./configure make which worked without issues and this system is certainly systemd-free, too. Which makes it even more non-sensical to make it have systemd dependencies. Could perhaps provide some kind of link illustrating what you were referring to? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789283 And from http://lists.clamav.net/pipermail/clamav-users/2015-June/001604.html BTW, since I'm the primary clamav maintainer in Debian, guess how much action your report is going to get. As you've pointed out, this is a package widely used across various OSs, and is still officially supported in Wheezy through security updates. But the Debian Jessie package hard depends on libsystemd0. Now I know some will call me paranoid, but if you're going to allow various libraries, then you are allowing part of the code that people are complaining about. I'm not able to go and examine the code, but I've seen enough of what systemd does and how it's coded to know I don't want it on servers I'm responsible for keeping running. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, 14 Aug 2015 20:03:49 +0200 Teodoro Santoni asbras...@gmail.com wrote: It's true, that's a waste, although very small, to add an if structure. Remains a weak argument: not being clamav a Go project, it has for sure a badly optimized, on the buiding side, codebase, so a config macro and an #ifdef SYSTEMD_EXISTS around the call surely doesn't waste anything valuable. :s/EXISTS/INFESTS/ /* Litt ducks and runs */ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, 8/14/15, T.J. Duchene t.j.duch...@gmail.com wrote: Subject: Re: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Friday, August 14, 2015, 2:47 PM I know not everyone here agrees with me, especially Steve, and that's perfectly okay. I have no problem with that at all. I just don't see System 5 pure as realistic when planning ahead looking at a maintenance standpoint when Debuan upstream is more and more likely to stick with Systemd in designing their packaging. Maybe we should just put Steve in charge of decontaminating all packages with systemd deps! If it is of any interest, the last time I tested Debian Sid a few days ago, it had the option on the Grub menu to choose to boot via System 5 or Systemd. Does that mean you can now install another init system without having to install systemd first? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Fri, 14 Aug 2015 20:26:58 -0400 Steve Litt sl...@troubleshooters.com wrote: Oh, you wouldn't want to do that. Contrary to what I wrote in another thread about the perfect is the enemy of the good, if *I* were in charge of decontamination, I'd throw out whole subsystems. LOL! =) One thing I say with the utmost respect, Steve, is that you do not dance around. I appreciate knowing exactly where you stand on something. And the people who prioritize pretty over functional and robust: I'd tell them to get a Mac. I don't get where that fits in, but then to be perfectly honest, I do not understand a great deal. I do not see any reason for the present day dichotomy in the software world. Good software design embodies all of those qualities. Anything less is shoddy work, and I despise not taking pride in the craft by making a real effort. If I had to effort some kind of idea what happened, I would have to blame the programmer, because they were disconnected from the process of providing what the user needs. And yes, I *am* a hypocrit who takes one position in one thread, and then says he'd do the opposite in another. :-) That's fine! =) Blunt honesty goes a long way with someone like myself. The only thing I ever ask from anyone is that even disagreements remain civil. DNG has had its moments, but I think we have been handling that pretty well lately. That is just my opinion, of course. Have a good night! T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
It seems to me that it's good to have shim programs that satisfy dependencies of apps on systemd, each shim performing some systemd function. Here's why: Suppose there are 10,000 application programs (apps) for Linux, and their developers foolishly insert dependencies on systemd. If Devuan developers write 50 simple shims to fulfill those dependencies, then Devuan users can run those 10,000 apps as they are, directly from the Debian repos. And when the apps are updated, they will still run. As pointed out already, unless the systemd calls are not actually doing anything useful to the operation of the program then replacing each call with a null operation will break the program. But, IMO there is a more important philosophical reason not to do it. If it were technically possible to create all these shims that would do nothing but magically still let programs work, by doing it that way you have legitimised the use of those systemd calls. As in, use as many as you like, it doesn't actually matter. If Devuan can get to the point where the devs that are blindly going down the systemd alley* want to get on board, without these shims there is a clear message - fix your code or it can't be installed. * I'm sure some feel they are using systemd calls for a good reason. In many cases there may well be merit in using them when available. As an example, I tried to upgrade one of my Wheezy systems to Jessie with *systemd* pinned as not installable. It took a bit of messing around figuring out what the broken dependencies were, and in the end I only had ONE single package that I needed and which wouldn't install - clamav-daemon (the other clamav* packages were fine, just not that individual one). In response to my messages on the clamav mailing list and bug report, it turns out that they only make ONE call to libsystemd during startup and then never use it again, and it's not even an essential call - but no, it would be a waste of CPU cycles to do a if exists libsystemd0 then call ... I assume it's not considered a waste of cycles to maintain a separate package for Wheezy security updates ! If you provide a shim, then you legitimise this sort of behaviour. Which would you prefer : a clamav-daemon package with a dependency on a fake libsystemd0, or a clamav-daemon package without any systemd dependency ? If you legitimise using shims, then the same people that see no reason to not hard-depend on libsystemd0 will bring you a package with a hard-depends on fake-libsystemd0. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Mark S Bilk m...@cosmicpenguin.com writes: It seems to me that it's good to have shim programs that satisfy dependencies of apps on systemd, each shim performing some systemd function. Here's why: Suppose there are 10,000 application programs (apps) for Linux, and their developers foolishly insert dependencies on systemd. [...] So using a relatively small number of shim programs in Devuan will save an enormous amount of work for the Devuan developers, which will allow them to use their time for more productive purposes -- making Devuan more generally useful and attractive, thereby gaining far more users. The end result of reimplementing systemd one-shim-at-a-time won't be distinguishable from just using systemd, minus the enormous amount of time wasted implementing all the shims. Since you frame this as unavoidable, you're thus effectively advocating use of systemd. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On 09.08.2015 12:02, Rainer Weikusat wrote: Mark S Bilk m...@cosmicpenguin.com writes: It seems to me that it's good to have shim programs that satisfy dependencies of apps on systemd, each shim performing some systemd function. Here's why: Suppose there are 10,000 application programs (apps) for Linux, and their developers foolishly insert dependencies on systemd. These 10.000 apps with depencies could become 10.000 debian packages with hard dependency to systemd. But if devuan removes the dependency once they could create a patch and use this patch automatically on the updated debian package... debian pkg xy - devuan developer -(creates)- devuan package and devuan patch; debian upgrades pkg xy - devuan build system applies the old patch -(if no errors)- package goes into testing... I hope this is understandable. I think in most cases one patch could uphold for a long time. Please think about that and stop developing shims :) All those shims will end up in having a systemd fork. [...] So using a relatively small number of shim programs in Devuan will save an enormous amount of work for the Devuan developers, which will allow them to use their time for more productive purposes -- making Devuan more generally useful and attractive, thereby gaining far more users. The end result of reimplementing systemd one-shim-at-a-time won't be distinguishable from just using systemd, minus the enormous amount of time wasted implementing all the shims. Since you frame this as unavoidable, you're thus effectively advocating use of systemd. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Patrick Erdmann p...@perdmann.de writes:
On 09.08.2015 12:02, Rainer Weikusat wrote:
Mark S Bilk m...@cosmicpenguin.com writes:
It seems to me that it's good to have shim programs that satisfy
dependencies of apps on systemd, each shim performing some systemd
function. Here's why:
Suppose there are 10,000 application programs (apps) for Linux,
and their developers foolishly insert dependencies on systemd.
[...]
I hope this is understandable. I think in most cases one patch could
uphold for a long time. Please think about that and stop developing
shims :) All those shims will end up in having a systemd fork.
A 'fork' would be something which started with the current systemd
codebase and would then either move in a different direction or at least
be maintained by different people. This would be worse as it would
amount to reimplementing the systemd APIs in a way intended to be
compatible with the beast itself but either without providing any real
functionality or with providing it in some other way than it is provided
by the systemd code itself. Ie, on the front side, it would 'feel and
look' exactly like a systemd-using system does but on the backside, it
would just be a sub-par implementation of systemd. It would also still
require a fair amount of neverending development work in order to
maintain this 'DINE' ('Devuan Is Not An Emulator') project
and could thus be pretty much regarded as worst-of-everything.
Borrowing a term Mr Poettering coined on Google+ a while ago:
One can pretty much imagine some sort of exhibition cage at a Linux
conference sporting a bunch of grey bearded (or greyingly bearded) men
in shirt-sleeves, busily hacking on their laptops with a big UNIX(*)
confusobeards busy with imitating something they could have gotten for
free badly. Bite sometimes. Keep your distance and don't try to feed.
sign on the front side ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
IMHO, if an external program calls a systemd API, does it because want that systemd does something. Write 10-100-1000 systemd shims that don't do anything, simply returns true is not a solution: in case, we have to translate the systemd api call to the real daemon in execution and this could be an effort bigger than evacuate systemd to 10.000 packages. On 08/08/15 17:49, Mark S Bilk wrote: It seems to me that it's good to have shim programs that satisfy dependencies of apps on systemd, each shim performing some systemd function. Here's why: Suppose there are 10,000 application programs (apps) for Linux, and their developers foolishly insert dependencies on systemd. If Devuan developers write 50 simple shims to fulfill those dependencies, then Devuan users can run those 10,000 apps as they are, directly from the Debian repos. And when the apps are updated, they will still run. The Devuan devs don't have to deal with those 10,000 updates at all. And the shim programs only have to be updated when the systemd API that they are emulating changes. Now suppose that systemd shims are not used. That means that all 10,000 apps have to be patched by Devuan developers so they don't depend on systemd. And all the 10,000 patched apps have to sit in a Devuan repo that has to be maintained. And every time one of those 10,000 apps is updated, the Devuan devs have to repatch it to remove the systemd dependencies and recompile it. The Devuan devs can request the app devs to remove the systemd dependencies, but that has a low probability of success, because the app devs have lemming-consciousness rather than Unix-consciousness, and think that systemd is fine because the major distros have adopted it. So using a relatively small number of shim programs in Devuan will save an enormous amount of work for the Devuan developers, which will allow them to use their time for more productive purposes -- making Devuan more generally useful and attractive, thereby gaining far more users. Now I realize that the idea of having those shim programs is going to make some Devuan people scream, Unclean! Unclean!. But the shim programs will be under our control and will save us a huge amount of constantly ongoing work of updating apps. And Devuan will succeed with only 25 developers and administrators instead of needing 500. So please drop the fear of contamination, and consider the shims as a simple, inexpensive and effective wall of defense against systemd. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Sat, 8/8/15, Mark S Bilk m...@cosmicpenguin.com wrote: Subject: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Saturday, August 8, 2015, 11:49 AM [cut] So please drop the fear of contamination, and consider the shims as a simple, inexpensive and effective wall of defense against systemd. Mark Interesting first post. I don't see how becoming entangled forever with systemd is a solution. Get to know Mark better at the URL implied in his email before embracing his 'wisdom'. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
From the look of Mark's website I was a bit disappointed not to find a link to www.davidicke.com! But, if the quick'n'dirty pragmatic solution is systemd shims then so be it as far as I am concerned. DaveT On 08/08/15 18:14, Go Linux wrote: On Sat, 8/8/15, Mark S Bilk m...@cosmicpenguin.com wrote: Subject: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Saturday, August 8, 2015, 11:49 AM [cut] So please drop the fear of contamination, and consider the shims as a simple, inexpensive and effective wall of defense against systemd. Mark Interesting first post. I don't see how becoming entangled forever with systemd is a solution. Get to know Mark better at the URL implied in his email before embracing his 'wisdom'. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
From the look of Mark's website I was a bit disappointed not to find a link to www.davidicke.com! But, if the quick'n'dirty pragmatic solution is systemd shims then so be it as far as I am concerned. DaveT On 08/08/15 18:14, Go Linux wrote: On Sat, 8/8/15, Mark S Bilk m...@cosmicpenguin.com wrote: Subject: [DNG] Systemd Shims To: dng@lists.dyne.org Date: Saturday, August 8, 2015, 11:49 AM [cut] So please drop the fear of contamination, and consider the shims as a simple, inexpensive and effective wall of defense against systemd. Mark Interesting first post. I don't see how becoming entangled forever with systemd is a solution. Get to know Mark better at the URL implied in his email before embracing his 'wisdom'. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
G'evening, On Sat, Aug 08, 2015 at 08:30:58PM +0100, Dave Turner wrote: From the look of Mark's website I was a bit disappointed not to find a link to www.davidicke.com! Well... I'm fine with what I saw, I mostly don't care because his beliefs are his own business. Yeah, even praising Ruby as the best lang is a personal belief, so transeamus. Off-topic. But, if the quick'n'dirty pragmatic solution is systemd shims then so be it as far as I am concerned. Are we talking about systemd-shim the software by Canonical, or shims for systemd compatibility? The systemd framework is a byzantine pile of features, so I can't say for sure whether stub functions added to init-neutral-to-be programs are hacks that should be replaced ASAP with snippets of more unixy, maybe ad hoc components or with calls to a uniform API, or not. logind is very difficult to emulate for example, but sometimes you mightnt just add stubs, ending with applications full of holes or regressions... -- Teodoro Santoni Something is wrong. I don't wanna compile 20 KB of Go code to list files. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
