komport-devel Mailing List for Komport
Status: Alpha
Brought to you by:
msharkey
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(17) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Trindade I. <ed...@tr...> - 2016-05-03 22:59:13
|
Esta mensagem foi enviada para o endereco kom...@li.... Se voce estiver com problemas para visualizar esta mensagem, copie o endereco abaixo e cole no seu navegador. http://e.trindadeimoveis.com.br/v3/TRC/P/3513/236348/205218347/ Para garantir o recebimento desta mensagem em sua caixa de entrada, adicione ed...@tr... a lista de remetentes confiaveis ou ao seu catalogo de enderecos. Caso voce queira cancelar o recebimento das mensagens e/ou denunciar abuso deste remetente, solicitamos que copie o endereco abaixo e cole no seu navegador. http://e.trindadeimoveis.com.br/v3/TRC/R/3513/236348/205218347/ |
From: <ben...@id...> - 2004-05-25 08:11:27
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Steven K. <skr...@f2...> - 2004-01-28 13:28:36
|
Very strange, Last night I searched on freshmeat for it and it didn't come up. But, it is there, so never mind. I'm snowed in today with pretty much nothing to do, so I'll compile the CVS sources and test them out and get back to you. SK Mike Sharkey wrote: >Steven, thanks. > >I have listed komport on freshmeat previously and gotten a lot of interest. >See http://freshmeat.net/projects/komport > >Sorry, I've been just really busy with my day job and with the aircraft fuel >injection project (efi11.sourceforge.net). The fuel injection project was >actually one of the factors that spawned komport. I knew I would need a >serial port terminal emulator to use during the firmware development of efi11 >and I was not looking forward to spending hours upon hours using minicom. > >I'm sure I won't have time to get another release out until next weekend at >the earliest. Meanwhile, If anyone else can checkout from CVS and do a build, >then by all means, feel free to go ahead and release that if it looks good. >The CVS code has a few bug fixes that should probably get released by now. If >you do so, please verify after building, that the version number that is >displayed has been incremented. > >I'll try to put a few more hours into komport in a few weekends from now. > >Also anybody who would like to do translations, please feel free, I'ev gotten >many of the strings into the komportstrings.h file. Those strings should not >be changing. I have yet to get the setup form strings in there. > >Cheers! > >Mike > >On Tuesday 27 January 2004 10:29 pm, Steven Kreuzer wrote: > > >>Hello Everybody, >> >>I just realized that komport is not listed on freshmeat.net >> >>Submitting the project there is a good way to get the word out and >>increase the user base. If no one has any objections, I would like to >>submit this project there. >> >>SK >> >> >> >> > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Komport-devel mailing list >Kom...@li... >https://lists.sourceforge.net/lists/listinfo/komport-devel > >. > > > |
From: Mike S. <mi...@sh...> - 2004-01-28 13:10:15
|
Steven, thanks. I have listed komport on freshmeat previously and gotten a lot of interest. See http://freshmeat.net/projects/komport Sorry, I've been just really busy with my day job and with the aircraft fuel injection project (efi11.sourceforge.net). The fuel injection project was actually one of the factors that spawned komport. I knew I would need a serial port terminal emulator to use during the firmware development of efi11 and I was not looking forward to spending hours upon hours using minicom. I'm sure I won't have time to get another release out until next weekend at the earliest. Meanwhile, If anyone else can checkout from CVS and do a build, then by all means, feel free to go ahead and release that if it looks good. The CVS code has a few bug fixes that should probably get released by now. If you do so, please verify after building, that the version number that is displayed has been incremented. I'll try to put a few more hours into komport in a few weekends from now. Also anybody who would like to do translations, please feel free, I'ev gotten many of the strings into the komportstrings.h file. Those strings should not be changing. I have yet to get the setup form strings in there. Cheers! Mike On Tuesday 27 January 2004 10:29 pm, Steven Kreuzer wrote: > Hello Everybody, > > I just realized that komport is not listed on freshmeat.net > > Submitting the project there is a good way to get the word out and > increase the user base. If no one has any objections, I would like to > submit this project there. > > SK > > |
From: Steven K. <skr...@f2...> - 2004-01-28 03:28:51
|
Hello Everybody, I just realized that komport is not listed on freshmeat.net Submitting the project there is a good way to get the word out and increase the user base. If no one has any objections, I would like to submit this project there. SK |
From: Robert B. <Rob...@rb...> - 2004-01-07 20:41:13
|
Steven Kreuzer wrote: > I took some screenshots of Komport connected to a cisco router under > a gnome session. If you guys want, feel free to post the screenshots on > the web site, but the pictures need to be cropped a little. Ok I've cropped this pictures and added them to the screenshots page. Regards, Robert Bachmann -- Rob...@rb... |
From: Mike S. <mi...@sh...> - 2004-01-07 18:43:50
|
Nice screen shots Steven! :) I've gotten even less work done on Komport than I had hoped. However, on the up side, I was discussing with a fellow about the possibility of developing a WYSE-150 emulation for Komport. I thought "why not"? It would be a good excuse to revisit the KomportEmulation class and also give something other than the VT102 option on the settings form. It would be a template for developers to use to develop other additional emulations. Also having a close look at the KomportEmulation class would give a chance to clean it up a bit, as there are a few things in there that I'm not that proud of. Any thoughts on this idea? Any other emulations we should persue? Anybody have the escape codes? --Mike On Monday 05 January 2004 08:17 pm, Steven Kreuzer wrote: > Hello Everybody, > > I took some screenshots of Komport connected to a cisco router under > a gnome session. If you guys want, feel free to post the screenshots on > the web site, but the pictures need to be cropped a little. > > http://skreuzer.f2o.org/projects/komport/cisco-boot.png > http://skreuzer.f2o.org/projects/komport/cisco-config.png > > SK > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
From: Steven K. <skr...@f2...> - 2004-01-06 01:17:23
|
Hello Everybody, I took some screenshots of Komport connected to a cisco router under a gnome session. If you guys want, feel free to post the screenshots on the web site, but the pictures need to be cropped a little. http://skreuzer.f2o.org/projects/komport/cisco-boot.png http://skreuzer.f2o.org/projects/komport/cisco-config.png SK |
From: Mike S. <mi...@sh...> - 2004-01-03 03:46:11
|
I havn't had as much time for Komport as I had hoped. I should have some time over the weekend to address a few things but not as much as I thought I'd get done by next week, but we'll see, the weekend is still young. Steven, I'll release this 0.5.9.RPM file this weekend, however, all you guys who are a member of the project, please feel free to release files! You should all have perms to access and modify CVS, and to release files. Sorry about this passed week, I just got some momentum going on the fuel injection controller for my airplane, and I did a few late nights and got the initial version of the main PC board layout completed and ready to send out for prototype manufacture (3 PC boards). Also I just started working on the firmware using gcc for MC68HC11. In any case, sorry, I got side tracked with that but I had to get started since I should have it to show at a gathering in a few months, and I'm still designing the sensor board. :( Anyway, I'll put some time (although not a great deal of it) into komport this weekend, and we'll get a new release out soon. :) --Mike On Sunday 28 December 2003 12:03 am, Steven Kreuzer wrote: > I just realized that Komport 0.5.9 was released. I created an RPM for it > and it can be found at: > > http://skreuzer.f2o.org/shenanigans/komport-0.5.9-1.i386.rpm > > Happy Hacking > > SK |
From: Steven K. <skr...@f2...> - 2003-12-28 13:29:28
|
I just realized that Komport 0.5.9 was released. I created an RPM for it and it can be found at: http://skreuzer.f2o.org/shenanigans/komport-0.5.9-1.i386.rpm Happy Hacking SK |
From: Mike S. <mi...@sh...> - 2003-12-23 17:49:03
|
Unfortunately I can't test them locally yet. I would suggest that if someone can test them, then go ahead and release them on sourceforge. --Mike Sharkey On Tuesday 23 December 2003 11:42 am, Wim Stubbe wrote: > Hello, > > I managed te make some debian packages (for sid) of komport-0.5.3 and > komport-0.5.9. > > These are my first steps, and I haven't had the time to test them fully > yet. If you don't mind, I would like to become an official packager in > time. > > You can find the packages at http://www.linuxbabe.be/komport > > If you test them and they seem to be ok, I wil gladly apply for inclusion > of komport into the debian project. > > Best regards, > > Wim Stubbe |
From: Wim S. <wi...@li...> - 2003-12-23 16:42:42
|
Hello, I managed te make some debian packages (for sid) of komport-0.5.3 and=20 komport-0.5.9.=20 These are my first steps, and I haven't had the time to test them fully yet= =2E=20 If you don't mind, I would like to become an official packager in time. You can find the packages at http://www.linuxbabe.be/komport If you test them and they seem to be ok, I wil gladly apply for inclusion o= f=20 komport into the debian project. Best regards, Wim Stubbe =2D-=20 http://www.openstandaarden.be |
From: Mike S. <mi...@sh...> - 2003-12-19 20:23:38
|
Sorry, I probably have not been describing the problem very clearly.....this is not a new problem, this has been a problem with un*x serial ports forever. The question is not if the user has write access to the /dev/ttyX device, but rather if someone else currently has the device open. The trouble is that the kernel allows multiple programs to open the serial port at the same time, which, as a matter of principal, is the way it should be. However, the kernel should respect the open() with O_EXCL (exclusive) flag on the serial ports, but it does not. So there is no way to tell if you have exclusive access to the port, or on the other hand if someone else already has exclusive access to the port. The only way to know if to implement and obey a locking protocol.s The traditional locking protocol involves creating /var/lock/LCK..ttyX style lock files that you are responsible for testing for the presence or absence (or staleness) of. It's ugly and requires setuid 0. Not to mention it's not always accurate because it does not take into account symlinks to the same device. Basically, it stinks. In other words, It's a lot of effort to implement something that does not even work very well. <sigh...> Basically, what I just put into CVS implements semaphore locking using System-V derived ipc (Inter Process Communication). It's very simple, does not require anybody to be setuid 0, and it take into account symlinks to the device file. It is really the way to go for this kind of situation......However, the down side is that it does not respect the old style of locks that minicom and friends use, so it will only handle the case of running two concurrent komport programs trying to access the same port. Which actually is probably the common case, as I've been doing that a lot myself inadvertently. As far as port (/dev/ttyX file) permissions go, it's not nessesary to be root (uid 0) to access /dev/ttyX. You can simply create a "serialuser" (or whatever) group in /etc/group and then change the group ownership of the serial device, like; "chgrp serialuser /dev/ttyX". Afterwards, then just add users who you wish to have access to /dev/ttyX to the "serialuser" group. Regards, --Mike On Friday 19 December 2003 02:45 pm, Steven Kreuzer wrote: > Wouldn't it be easier to require the user running the program to have a > UID of 0 > > Simply checking if the user has read and write privilages on the device at > startup, and if not, display an error message and quit. > > SK > > > If you obtain the latest CVS sources, you will see that I've implemented > > ipc > > style semaphore locking in the KomportLock class. > > > > If you now try to run two instances of komport on the same device you > > will > > see how the second instance will be locked out from accessing the device. > > However this still does not resolve the issue when running another app > > such > > as minicom on the same device. > > > > Still I feel that this current method is useful in that it handles the > > more > > common case of inadvertently attempting to access the same device from > > multiple instances of komport. > > > > This also handles the symlink case (i.e. /dev/ttyS0 == /dev/modem) > > because ftok() uses the resolved inode number in building the key used > > to select the > > semaphore, so you will get the same key from any symlinks which resolve > > to the same device file. > > > > If you happen to get stuck with a dangling semaphore due to an abrupt > > program > > termination (signal 11 for example), then you have to use the ipc tools > > to remove the dangling semaphore (ipcs, and ipcrm). > > > > Now, if we could just get everyone else to use this same protocol..... :) > > > > Anyway, my feeling at this stage is that we leave it like this and just > > see > > what reaction we get. Or, in other words, when you're not sure what to > > do, do > > nothing. > > > > Regards, > > > > Mike > > > > On Friday 19 December 2003 09:38 am, Mike Sharkey wrote: > >> I've started working on the new KomportLock class right now. I would > >> like > >> this to be able to lock the port in a way that's compatible with other > >> serial port programs such as uucp, ppp, minicom, fax, etc... > >> > >> This means using lock files, as ugly as that may be. > >> > >> The lock file should be /var/lock/LCK..<device>, such as > >> /var/lock/LCK..ttyS0, and should contain the process ID number of the > >> owner > >> process. > >> > >> I've always thought this was dumb, but it's the way the other programs > >> work > >> so I guess we have little choice. > >> > >> My question is regarding setuid. You may already be aware that /var/lock > >> is > >> not world writable, the way other programs get around this is by being > >> setuid 0 (root). Historically, the need to run setruid 0 has opened up > >> numerous exploits in minicom and others. > >> > >> I can see four options so far: > >> > >> 1) We run setuid 0 like minicom and the others. Although, this is the > >> simplest in term of effort, I don't like at all because it's a complex > >> program (Qt GUI etc...) and would be impossible to make it reasonably > >> secure from local exploits. > >> > >> 2) We develop an external lock file helper or daemon that runs setuid 0. > >> This program would be very simple and relatively easy to make secure. > >> The > >> program would have only two functions, obtain a lock file, and release a > >> lock file. > >> > >> 3) We use the existing sudo system for running either komport itself, or > >> an > >> external helper. > >> > >> 4) Forget about compatibility with ancient serial port programs and > >> develop > >> a new modern locking system using semaphores. Unless others would adopt > >> this same protocol, then komport will only be able to lock against other > >> instances of komport. For my needs this would be fine since komport is > >> the > >> only thing I run against my serial port devices. > >> > >> I vote #4 although I know that would get a lot of complaints, but it > >> would > >> bring the issue of using those out dated lock files to the front burner. > >> There aer a lot of problems with those lock files, not only the ones > >> I've > >> pointed out regarding setuid issues, but also the idea that the same > >> device > >> can have unlimited number of symlinks, for example, /dev/ttyS0 and > >> /dev/modem. > >> > >> I say it's high time we develop a new modernized protocol for locking > >> serial devices. Anybody with me on that? > >> > >> Mike Sharkey > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: IBM Linux Tutorials. > >> Become an expert in LINUX or just sharpen your skills. Sign up for > >> IBM's > >> Free Linux Tutorials. Learn everything from the bash shell to sys > >> admin. > >> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > >> _______________________________________________ > >> Komport-devel mailing list > >> Kom...@li... > >> https://lists.sourceforge.net/lists/listinfo/komport-devel > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IBM Linux Tutorials. > > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > _______________________________________________ > > Komport-devel mailing list > > Kom...@li... > > https://lists.sourceforge.net/lists/listinfo/komport-devel > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
From: Steven K. <skr...@f2...> - 2003-12-19 19:45:23
|
Wouldn't it be easier to require the user running the program to have a UID of 0 Simply checking if the user has read and write privilages on the device at startup, and if not, display an error message and quit. SK > If you obtain the latest CVS sources, you will see that I've implemented > ipc > style semaphore locking in the KomportLock class. > > If you now try to run two instances of komport on the same device you > will > see how the second instance will be locked out from accessing the device. > However this still does not resolve the issue when running another app > such > as minicom on the same device. > > Still I feel that this current method is useful in that it handles the > more > common case of inadvertently attempting to access the same device from > multiple instances of komport. > > This also handles the symlink case (i.e. /dev/ttyS0 == /dev/modem) because > ftok() uses the resolved inode number in building the key used to select > the > semaphore, so you will get the same key from any symlinks which resolve to > the same device file. > > If you happen to get stuck with a dangling semaphore due to an abrupt > program > termination (signal 11 for example), then you have to use the ipc tools to > remove the dangling semaphore (ipcs, and ipcrm). > > Now, if we could just get everyone else to use this same protocol..... :) > > Anyway, my feeling at this stage is that we leave it like this and just > see > what reaction we get. Or, in other words, when you're not sure what to do, > do > nothing. > > Regards, > > Mike > > > On Friday 19 December 2003 09:38 am, Mike Sharkey wrote: >> I've started working on the new KomportLock class right now. I would >> like >> this to be able to lock the port in a way that's compatible with other >> serial port programs such as uucp, ppp, minicom, fax, etc... >> >> This means using lock files, as ugly as that may be. >> >> The lock file should be /var/lock/LCK..<device>, such as >> /var/lock/LCK..ttyS0, and should contain the process ID number of the >> owner >> process. >> >> I've always thought this was dumb, but it's the way the other programs >> work >> so I guess we have little choice. >> >> My question is regarding setuid. You may already be aware that /var/lock >> is >> not world writable, the way other programs get around this is by being >> setuid 0 (root). Historically, the need to run setruid 0 has opened up >> numerous exploits in minicom and others. >> >> I can see four options so far: >> >> 1) We run setuid 0 like minicom and the others. Although, this is the >> simplest in term of effort, I don't like at all because it's a complex >> program (Qt GUI etc...) and would be impossible to make it reasonably >> secure from local exploits. >> >> 2) We develop an external lock file helper or daemon that runs setuid 0. >> This program would be very simple and relatively easy to make secure. >> The >> program would have only two functions, obtain a lock file, and release a >> lock file. >> >> 3) We use the existing sudo system for running either komport itself, or >> an >> external helper. >> >> 4) Forget about compatibility with ancient serial port programs and >> develop >> a new modern locking system using semaphores. Unless others would adopt >> this same protocol, then komport will only be able to lock against other >> instances of komport. For my needs this would be fine since komport is >> the >> only thing I run against my serial port devices. >> >> I vote #4 although I know that would get a lot of complaints, but it >> would >> bring the issue of using those out dated lock files to the front burner. >> There aer a lot of problems with those lock files, not only the ones >> I've >> pointed out regarding setuid issues, but also the idea that the same >> device >> can have unlimited number of symlinks, for example, /dev/ttyS0 and >> /dev/modem. >> >> I say it's high time we develop a new modernized protocol for locking >> serial devices. Anybody with me on that? >> >> Mike Sharkey >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IBM Linux Tutorials. >> Become an expert in LINUX or just sharpen your skills. Sign up for >> IBM's >> Free Linux Tutorials. Learn everything from the bash shell to sys >> admin. >> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >> _______________________________________________ >> Komport-devel mailing list >> Kom...@li... >> https://lists.sourceforge.net/lists/listinfo/komport-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel > |
From: Mike S. <mi...@sh...> - 2003-12-19 17:58:10
|
If you obtain the latest CVS sources, you will see that I've implemented ipc style semaphore locking in the KomportLock class. If you now try to run two instances of komport on the same device you will see how the second instance will be locked out from accessing the device. However this still does not resolve the issue when running another app such as minicom on the same device. Still I feel that this current method is useful in that it handles the more common case of inadvertently attempting to access the same device from multiple instances of komport. This also handles the symlink case (i.e. /dev/ttyS0 == /dev/modem) because ftok() uses the resolved inode number in building the key used to select the semaphore, so you will get the same key from any symlinks which resolve to the same device file. If you happen to get stuck with a dangling semaphore due to an abrupt program termination (signal 11 for example), then you have to use the ipc tools to remove the dangling semaphore (ipcs, and ipcrm). Now, if we could just get everyone else to use this same protocol..... :) Anyway, my feeling at this stage is that we leave it like this and just see what reaction we get. Or, in other words, when you're not sure what to do, do nothing. Regards, Mike On Friday 19 December 2003 09:38 am, Mike Sharkey wrote: > I've started working on the new KomportLock class right now. I would like > this to be able to lock the port in a way that's compatible with other > serial port programs such as uucp, ppp, minicom, fax, etc... > > This means using lock files, as ugly as that may be. > > The lock file should be /var/lock/LCK..<device>, such as > /var/lock/LCK..ttyS0, and should contain the process ID number of the owner > process. > > I've always thought this was dumb, but it's the way the other programs work > so I guess we have little choice. > > My question is regarding setuid. You may already be aware that /var/lock is > not world writable, the way other programs get around this is by being > setuid 0 (root). Historically, the need to run setruid 0 has opened up > numerous exploits in minicom and others. > > I can see four options so far: > > 1) We run setuid 0 like minicom and the others. Although, this is the > simplest in term of effort, I don't like at all because it's a complex > program (Qt GUI etc...) and would be impossible to make it reasonably > secure from local exploits. > > 2) We develop an external lock file helper or daemon that runs setuid 0. > This program would be very simple and relatively easy to make secure. The > program would have only two functions, obtain a lock file, and release a > lock file. > > 3) We use the existing sudo system for running either komport itself, or an > external helper. > > 4) Forget about compatibility with ancient serial port programs and develop > a new modern locking system using semaphores. Unless others would adopt > this same protocol, then komport will only be able to lock against other > instances of komport. For my needs this would be fine since komport is the > only thing I run against my serial port devices. > > I vote #4 although I know that would get a lot of complaints, but it would > bring the issue of using those out dated lock files to the front burner. > There aer a lot of problems with those lock files, not only the ones I've > pointed out regarding setuid issues, but also the idea that the same device > can have unlimited number of symlinks, for example, /dev/ttyS0 and > /dev/modem. > > I say it's high time we develop a new modernized protocol for locking > serial devices. Anybody with me on that? > > Mike Sharkey > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
From: Mike S. <mi...@sh...> - 2003-12-19 14:38:30
|
I've started working on the new KomportLock class right now. I would like this to be able to lock the port in a way that's compatible with other serial port programs such as uucp, ppp, minicom, fax, etc... This means using lock files, as ugly as that may be. The lock file should be /var/lock/LCK..<device>, such as /var/lock/LCK..ttyS0, and should contain the process ID number of the owner process. I've always thought this was dumb, but it's the way the other programs work so I guess we have little choice. My question is regarding setuid. You may already be aware that /var/lock is not world writable, the way other programs get around this is by being setuid 0 (root). Historically, the need to run setruid 0 has opened up numerous exploits in minicom and others. I can see four options so far: 1) We run setuid 0 like minicom and the others. Although, this is the simplest in term of effort, I don't like at all because it's a complex program (Qt GUI etc...) and would be impossible to make it reasonably secure from local exploits. 2) We develop an external lock file helper or daemon that runs setuid 0. This program would be very simple and relatively easy to make secure. The program would have only two functions, obtain a lock file, and release a lock file. 3) We use the existing sudo system for running either komport itself, or an external helper. 4) Forget about compatibility with ancient serial port programs and develop a new modern locking system using semaphores. Unless others would adopt this same protocol, then komport will only be able to lock against other instances of komport. For my needs this would be fine since komport is the only thing I run against my serial port devices. I vote #4 although I know that would get a lot of complaints, but it would bring the issue of using those out dated lock files to the front burner. There aer a lot of problems with those lock files, not only the ones I've pointed out regarding setuid issues, but also the idea that the same device can have unlimited number of symlinks, for example, /dev/ttyS0 and /dev/modem. I say it's high time we develop a new modernized protocol for locking serial devices. Anybody with me on that? Mike Sharkey |
From: Mike S. <mi...@sh...> - 2003-12-18 18:00:09
|
Hi All, Just not let everyone interested to know that host96 is back and is operating at 100% capacity with a new TYAN Tiger MPX S2466 (Rev 1.20) main board. The good news is that the old CPUs and RAM did not get cooked in the previous melt down. Host96 seems to be running really nicely so far. I'll be running sensor monitors from now on to monitor CPU temperature, fan speed, and power supply voltage, and will email me if any of those fall out of line. Just a small note on the internal network while I'm at it, I've changed the internal network from primrose.net to sharkey.serevbeer.com, thus host96.primrose.net becomes host96.sharkey.servebeer.com. <off topic> Anybody using any tape drives for backup? Any good or bad comments about particular vendors, or media? Okay, now that the painful episode is over, I'm back to work on komport....... Regards, Mike Sharkey |
From: Mike S. <mi...@sh...> - 2003-12-16 04:17:19
|
I have a very very small complaint. How come nobody is logging any Komport bugs on SourceForge except for me? :) Every time I try to use Komport, I see bugs, many of them. Am I the only one that sees them? Please don't assume I've seen them, or let alone, assume that I've logged them, I am probably the worst person in the world to count on for logging bugs. Also, more importantly, I would like to know how other people feel about the priority of particular bugs........So have no shame Man....complain!! Man! Get it off your chest!! That nagging, that perpetually gnawing feeling, that, "why won't that guy fix that damn thing?!?!?!?" feeling. :) Pick a bug and assign it to me on SourceForge. I will fix it. PS. Brick Amber Beer Rocks! :) (If you're in Canada you know what I'm talking about -- stubbies --, otherwise sorry ignore it). --Mike |
From: Mike S. <mi...@sh...> - 2003-12-16 03:17:07
|
Yeah, Steven, It's a very good point, and it's something I've been trying to ignore for far too long, yet I've allowed myself to loose sleep over it at the same time. Not just for Komport, but there are a few other projects (see http://sharkey.servebeer.com/~michael and there are also some not listed there) whose only existence on earth is on either sharkey.servebeer.com and/or host96. Actually (off topic), now that I'm mentioning those other projects, I'm hoping that some of your guys might want to help on some of those other projects next, but that's for another discussion at another time, we need to get Komport in the bag first...... Currently I do about a monthly backup on CD of projects and important things. I don't feel that it's enough but it's all I really have the capacity for, both in terms of time and machinery. I try to at least regularly mirror important stuff between at least two machines at all times in case of a hard drive failure. But certainly I must admit that it is far from ideal, and there is unquestionably room for improvement. I've been thinking about a mag tape. I have not looked into mag tape for probably about 6-8 years so any input would be welcome. The last mag tape drive I had was on a 368DX and it was a SCSI tape drive capable of 100MB of backup per tape. I know they have come a long way since then. :) In any case, with respect to Komport, I think we should be sure to try and keep the most recent stuff checked into the repository at SourceForge for the time being. Thanks Steven for bringing this to the front burner. Oh, and Cheers All! :) Hope you all are having as nice of a lead in to Christmas as I am! :) --Mike On Monday 15 December 2003 09:07 pm, Steven Kreuzer wrote: > Do you have a backup solution on host96, or should we all take care of > our own stuff? > > SK > > On Tue, 2003-12-16 at 05:50, Mike Sharkey wrote: > > ....Sorry guys if you've been trying to access host96. Since the power > > failure several days ago, host96 was acting up and now finally quit due > > to a power supply failure, and main board failure....I don't know which > > failed first and presumably caused the other to fail, but I'm assuming > > the power supply was the first to fail due to the recent power > > fluctuations....but who really knows...... > > > > In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this > > is not a cheap main board. Hopefully the CPUs are still good, because if > > not, this is gonna be a really expensive failure. Meanwhile host96 is up > > and limping with a new 2GHz Celeron main board with 1GB of ram. All hard > > discs are okay, and any work you have there should still be okay. > > > > I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 > > days, after which I will be installing the new 2GHz Celeron board into > > sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat > > Dual P233 board. > > > > --Management > > sharkey.servebeer.com > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Komport-devel mailing list > > Kom...@li... > > https://lists.sourceforge.net/lists/listinfo/komport-devel > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
From: Steven K. <skr...@f2...> - 2003-12-16 02:07:50
|
Do you have a backup solution on host96, or should we all take care of our own stuff? SK On Tue, 2003-12-16 at 05:50, Mike Sharkey wrote: > ....Sorry guys if you've been trying to access host96. Since the power failure > several days ago, host96 was acting up and now finally quit due to a power > supply failure, and main board failure....I don't know which failed first and > presumably caused the other to fail, but I'm assuming the power supply was > the first to fail due to the recent power fluctuations....but who really > knows...... > > In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this is > not a cheap main board. Hopefully the CPUs are still good, because if not, > this is gonna be a really expensive failure. Meanwhile host96 is up and > limping with a new 2GHz Celeron main board with 1GB of ram. All hard discs > are okay, and any work you have there should still be okay. > > I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 days, > after which I will be installing the new 2GHz Celeron board into > sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat Dual > P233 board. > > --Management > sharkey.servebeer.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel > |
From: Mike S. <mi...@sh...> - 2003-12-15 23:50:04
|
By the way, this 2GHz Celeron feels like about 1/4 of the speed of the dual AMD Athlon, you can really feel the difference in the GUI, and compile time is quite noticeably slower. :( --Mike On Tuesday 16 December 2003 05:50 am, Mike Sharkey wrote: > ....Sorry guys if you've been trying to access host96. Since the power > failure several days ago, host96 was acting up and now finally quit due to > a power supply failure, and main board failure....I don't know which failed > first and presumably caused the other to fail, but I'm assuming the power > supply was the first to fail due to the recent power fluctuations....but > who really knows...... > > In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this is > not a cheap main board. Hopefully the CPUs are still good, because if not, > this is gonna be a really expensive failure. Meanwhile host96 is up and > limping with a new 2GHz Celeron main board with 1GB of ram. All hard discs > are okay, and any work you have there should still be okay. > > I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 days, > after which I will be installing the new 2GHz Celeron board into > sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat > Dual P233 board. > > --Management > sharkey.servebeer.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
From: Mike S. <mi...@sh...> - 2003-12-15 22:49:56
|
....Sorry guys if you've been trying to access host96. Since the power failure several days ago, host96 was acting up and now finally quit due to a power supply failure, and main board failure....I don't know which failed first and presumably caused the other to fail, but I'm assuming the power supply was the first to fail due to the recent power fluctuations....but who really knows...... In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this is not a cheap main board. Hopefully the CPUs are still good, because if not, this is gonna be a really expensive failure. Meanwhile host96 is up and limping with a new 2GHz Celeron main board with 1GB of ram. All hard discs are okay, and any work you have there should still be okay. I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 days, after which I will be installing the new 2GHz Celeron board into sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat Dual P233 board. --Management sharkey.servebeer.com |
From: Mike S. <mi...@sh...> - 2003-12-13 13:59:45
|
sharkey.servebeer.com was offline during about a 12 hour local power interruption. Our backup power generators struggled valiantly to save the data processing center from going offline......for about 15 minutes.....at which time they scummed to the overwhelming load of the mega machines which occupy the sprawling data processing center. :) Service has now been restored....sorry for any trouble it may have caused. ---Management sharkey.servebeer.com |
From: Mike S. <mi...@sh...> - 2003-12-04 17:36:35
|
Good points, Mark. When I have a moment, I'll make sure we can checkout and build from CVS, I think everything that's currently checked in should build. Just a heads up that the code in CVS is now newer than 0.5.9. Next time I have some time to work on Komport, I will be addressing the high priority TODO items roughly in the order they are listed. This will include getting the remaining strings into komportstrings.h so we can start with translations. I've been doing a little thinking this morning about text selection. First, I would like to add a text selection mode toggle that toggles between selecting rectangular area (the current way), and selecting in line mode (ala xterm). First, are there any thoughts about that? Secondly, I would like to add a menu item Edit->Select_All, but I have a few questions about that. Should Select_All only select the text in the viewport bounds, or should it select the viewport and also include the history buffer. Or should there be two separate select-all functions, one for viewport, and one for history? If so, should the Select_All_History function also select the viewport text or only the text which has scrolled into the history? Hmmmm.....I may need to consult with Mr Red Cap again..... On Thursday 04 December 2003 03:32 am, Mark wrote: > To start this discussion regarding CVS usage and tagging of files, my > experience from some experienced individuals is to keep commits specific > to a change if possible. Searching the comments can help find the > change or future issues. (Radical rewrites of course do not count and > might be a reason to branch at some point?) The key they feel is to > make sure that whatever is in CVS compiles. (Again another case for a > branch of the code in CVS if/when necessary.) > > My goal at some point is to get the tagging of every release made and > see whatever else I can do with what SF allows. (Already behind with > 0.5.9, I know) My thought on releasing an 'unstable' version is to hold > off for right now. If someone is interested, they can checkout from > anonymous CVS the latest which may or may not work ("unstable"). > > As you may or may not have noticed, the packaging source has not been > added to CVS. If someone could send me at least some of the files to > have a base with, I will tag appropriately to move on. (Thought I sent > an e-mail to Steven but might have been bounced?) > > Mark > > Mike Sharkey wrote: > > Hi All, > > > > I think I've successfully committed the changes to bring the repository > > up to the latest 0.5.9 version (I had to make a few bug fixes after > > 0.5.8). People should now be able to build the latest from the > > repository. > > > > Let me know how it goes, please. > > > > Everyone involved in the project should have write access to the > > repository. Please let me know if you need an adjustment to your > > privileges. > > > > Mark, I'm hoping you will keep everyone in line with respect to > > repository discipline. Maybe you could draft a set of basic guidelines. > > > > What I would like is to be able to have tags or some mechanism to get to > > the last buildable and runnable version. Anyone else have any input on > > repository discipline? > > > > Should we have a "stable" and "unstable" branch perhaps? I don't know, > > I'm asking the CVS experts. > > > > In any case, I will be working from CVS from now on. Any of you who are > > interested in doing some KDE/C++ programming, please by all means feel > > free. > > > > :) > > > > A few house keeping chores and some TODO items I think we should get done > > over the next little while: > > > > * Put all string constants into one header file to simplify localization > > as per Robert's earlier suggestion. > > > > * Update the ChangeLog, AUTHORS, README, TODO files to contain useful > > information..... > > > > * Get package files (.spec, etc...) into repository. > > > > I'll work on the TODO list next, as I think that's my biggest task right > > now is to prioritize coding items for the 0.6 release. > > > > Well, it's really looking good, thanks everyone for helping out! > > > > Cheers all! > > > > --Mike > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
From: Mark <m....@sh...> - 2003-12-04 08:37:06
|
To start this discussion regarding CVS usage and tagging of files, my experience from some experienced individuals is to keep commits specific to a change if possible. Searching the comments can help find the change or future issues. (Radical rewrites of course do not count and might be a reason to branch at some point?) The key they feel is to make sure that whatever is in CVS compiles. (Again another case for a branch of the code in CVS if/when necessary.) My goal at some point is to get the tagging of every release made and see whatever else I can do with what SF allows. (Already behind with 0.5.9, I know) My thought on releasing an 'unstable' version is to hold off for right now. If someone is interested, they can checkout from anonymous CVS the latest which may or may not work ("unstable"). As you may or may not have noticed, the packaging source has not been added to CVS. If someone could send me at least some of the files to have a base with, I will tag appropriately to move on. (Thought I sent an e-mail to Steven but might have been bounced?) Mark Mike Sharkey wrote: > Hi All, > > I think I've successfully committed the changes to bring the repository up to > the latest 0.5.9 version (I had to make a few bug fixes after 0.5.8). People > should now be able to build the latest from the repository. > > Let me know how it goes, please. > > Everyone involved in the project should have write access to the repository. > Please let me know if you need an adjustment to your privileges. > > Mark, I'm hoping you will keep everyone in line with respect to repository > discipline. Maybe you could draft a set of basic guidelines. > > What I would like is to be able to have tags or some mechanism to get to the > last buildable and runnable version. Anyone else have any input on repository > discipline? > > Should we have a "stable" and "unstable" branch perhaps? I don't know, I'm > asking the CVS experts. > > In any case, I will be working from CVS from now on. Any of you who are > interested in doing some KDE/C++ programming, please by all means feel free. > :) > > A few house keeping chores and some TODO items I think we should get done over > the next little while: > > * Put all string constants into one header file to simplify localization as > per Robert's earlier suggestion. > > * Update the ChangeLog, AUTHORS, README, TODO files to contain useful > information..... > > * Get package files (.spec, etc...) into repository. > > I'll work on the TODO list next, as I think that's my biggest task right now > is to prioritize coding items for the 0.6 release. > > Well, it's really looking good, thanks everyone for helping out! > > Cheers all! > > --Mike |