Re: Promiscuous ports under Linux
On Thu, 4 May 2017 18:04:02 + (UTC), Grant Edwards wrote: > On 2017-05-04, Peter Pearson wrote: > >> I'm curious to survey all my LAN traffic in various ways, and it seems >> likely that I will see phenomena that I don't understand, and focussing >> in on those phenomena is likely to require more flexible filtering >> than Wireshark can provide. I expect to leave this process running for >> maybe 24 hours at a stretch, maybe longer, with real-time alerts when >> interesting things occur. > > You can libpcap (which is what wireshark uses on Linux) to deal with > the details of capturing the packets and do the analysis in Python. > >> Maybe Wireshark can do everything I'll ever need to do, but it seems >> so complicated, and Python seems so simple . . . > > I've been using pylibpcap for yonks, and have no complaints. > > https://sourceforge.net/projects/pylibpcap/ [snip] Hey, that might do the job. Thanks! -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Elegant way to merge dicts without overwriting keys?
Malcolm Greene wrote:
> I have a bunch of pickled dicts I would like to merge. I only want to
> merge unique keys but I want to track the keys that are duplicated
> across dicts. Is there a newer dict-like data structure that is fine
> tuned to that use case?
> Short of an optimized data structure, my plan is to convert dict keys to
> sets and compare these sets to determine which keys are unique and can
> be merged and which keys are dupes and should be tracked in that manner.
> At a high level, does this sound like a reasonable approach?
> Thank you,
> Malcolm
Do you want
merge(dict(a=1, b=2), dict(a=10, c=30)) --> dict(b=2, c=30)
or
merge(dict(a=1, b=2), dict(a=10, c=30)) --> dict(a=1, b=2, c=30)
? In the latter case just reverse the updates, in the former you can operate
directly on the keys:
>>> a = dict(a=1, b=2)
>>> b = dict(a=10, c=30)
>>> a.keys() & b.keys()
{'a'}
>>> a.keys() ^ b.keys()
{'c', 'b'}
For Python 2 replace keys() with viewkeys().
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 on Windows: Copy&Paste install
On Thu, May 4, 2017 at 8:27 PM, jeff saremi wrote: > I have scoured the net for any hints on this. We have some prod machines > where we're not able to run MSI installations. > Is it possible to copy Python2.7 from say c:\Python2.7 from one machine to > another? > What other steps do we need beyond the following since these DONT work: Before going deeper into writing scripts to manually install Python, have you considered using a portable version such as WinPython [1]. It has an option to register itself. [1]: https://winpython.github.io > 3. Add C:\python2.7\Lib and C:\python2.7\Lib\site-packages to PYTHONPATH Did someone tell you to do that? If so, please tell them it's wrong. PYTHONPATH should never include those directories. It takes precedence over the standard library, so adding those directories will break other versions of Python on the system. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7: no such module pip
On Thu, May 4, 2017 at 8:24 PM, jeff saremi wrote: > Did a fresh install of python-2.7.amd64.msi on windows 10. > > The install finishes with success. Python runs. No pip when the following is > run: > > C:\> python -m pip install elastalert > C:\Python27\python.exe: No module named pip Maybe you didn't select the option to install pip, or maybe it failed and wasn't reported. Try installing the bundled pip manually: python -m ensurepip -Uv -- https://mail.python.org/mailman/listinfo/python-list
Python 2.7: no such module pip
Did a fresh install of python-2.7.amd64.msi on windows 10. The install finishes with success. Python runs. No pip when the following is run: C:\> python -m pip install elastalert C:\Python27\python.exe: No module named pip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 on Windows: Copy&Paste install
On 2017-05-04 21:27, jeff saremi wrote: I have scoured the net for any hints on this. We have some prod machines where we're not able to run MSI installations. Is it possible to copy Python2.7 from say c:\Python2.7 from one machine to another? What other steps do we need beyond the following since these DONT work: 1. Copy all files 2. Add the new Python2.7\bin to PATH 3. Add C:\python2.7\Lib and C:\python2.7\Lib\site-packages to PYTHONPATH thanks Jeff There's also python27.dll in C:\Windows\System32. -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On 04May2017 20:42, Wildman wrote: On Fri, 05 May 2017 09:00:58 +1000, Cameron Simpson wrote: On 04May2017 15:03, Wildman wrote: The program installs using the Debian package system (.deb) and an entry is created in the Applications Menu. The strange thing is that the crash only occurs when the program is run from the menu. If I open a terminal and run the program from there, the program runs fine. And this supports that. getlogin is not magic, and can be overused. The Python docs say "Return the name of the user logged in on the controlling terminal of the process." Clearly that will fail. When you start from a terminal, your command will have that as its controlling terminal unless it has gone out of its way not to. When you start from a menu, usually that menu system will not be associated with a terminal. In this case you need to fall back on other methods of figuring out "who is logged in". What I don't understand is why the program will run from the menu on some Linux distros and not others. I might need to take a closer look at the structure of the .desktop file used to launch my program. Thanks. I presume it will come down (in this instance) to the controlling tty. Put some testing code into something you can invoke from a menu. Try to open '/dev/tty' and see what error results. See if stdin, stdout and stderr are attached to terminals (or even open). You can os.fstat(sys.stdin.fileno()) and so forth. And direct stderr to a logfile so you get to see any stack traces; you can write other info there, or dup stdout to the same logfile. You can "tail -f" the logfile from a terminal to see your test results easily. It may also depend on how X11 is started. On some distros you may have a GUI login, and your X11 session may have no controlling terminal. On my systems I run text consoles and use "startx" to kick things off. I'd expect my window manager etc to have a controlling tty, the console. Unless something lets go of it deliberately before kicking off my desktop. So you're right, different distros and setups may well present somewhat different inherited environments to whatever presents your menus. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
bugs.python.org registration never completes
i've been waiting for my confirmation email. Never received it Someone should look into the registration. And there is no admin emails where you could send your issue to! thanks Jeff -- https://mail.python.org/mailman/listinfo/python-list
Python 2.7 on Windows: Copy&Paste install
I have scoured the net for any hints on this. We have some prod machines where we're not able to run MSI installations. Is it possible to copy Python2.7 from say c:\Python2.7 from one machine to another? What other steps do we need beyond the following since these DONT work: 1. Copy all files 2. Add the new Python2.7\bin to PATH 3. Add C:\python2.7\Lib and C:\python2.7\Lib\site-packages to PYTHONPATH thanks Jeff -- https://mail.python.org/mailman/listinfo/python-list
Re: Elegant way to merge dicts without overwriting keys?
On 2017-05-05 02:23, Malcolm Greene wrote: I have a bunch of pickled dicts I would like to merge. I only want to merge unique keys but I want to track the keys that are duplicated across dicts. Is there a newer dict-like data structure that is fine tuned to that use case? Short of an optimized data structure, my plan is to convert dict keys to sets and compare these sets to determine which keys are unique and can be merged and which keys are dupes and should be tracked in that manner. At a high level, does this sound like a reasonable approach? Thank you, Malcolm (Assuming Python 3.) Suppose you have a number of dicts: dict_1 dict_2 dict_3 Collect all of their keys into a list: all_keys = list(dict_1) + list(dict_2) + list(dict_3) How many times does each of the keys occur? from collections import Counter key_count = Counter(all_keys) Which keys are unique? unique_keys = [key for key in all_keys if key_count[key] == 1] -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, May 5, 2017 at 12:05 PM, Wildman via Python-list wrote: > On Fri, 05 May 2017 09:58:02 +1000, Chris Angelico wrote: > >> On Fri, May 5, 2017 at 9:50 AM, Wildman via Python-list >> wrote: >>> I'm afraid that won't work. The user environment is different >>> than root. A different set of variables. However you have >>> given me a possible workaround. You can't create a variable >>> for root unless you are root so that approach is out. But >>> it might be possible to create the variable for the user >>> and access it as root. I don't have a lot of experience >>> using os.environ, but I am going to at it closer. >> >> When you start a subprocess, it inherits your environment. So you can >> create an environment variable for yourself, then start the other >> process. > > I solved this problem by passing the user name to the second > instance as a command line argument. Works perfectly. It > escapes me why I didn't think of this sooner. I solved the > os.login problem by not using os.login, since I no longer > need it. :-) That works too! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, 05 May 2017 09:58:02 +1000, Chris Angelico wrote: > On Fri, May 5, 2017 at 9:50 AM, Wildman via Python-list > wrote: >> I'm afraid that won't work. The user environment is different >> than root. A different set of variables. However you have >> given me a possible workaround. You can't create a variable >> for root unless you are root so that approach is out. But >> it might be possible to create the variable for the user >> and access it as root. I don't have a lot of experience >> using os.environ, but I am going to at it closer. > > When you start a subprocess, it inherits your environment. So you can > create an environment variable for yourself, then start the other > process. I solved this problem by passing the user name to the second instance as a command line argument. Works perfectly. It escapes me why I didn't think of this sooner. I solved the os.login problem by not using os.login, since I no longer need it. :-) > But read Cameron's cautionary notes and basically just don't do this. > > ChrisA It has been my experience that Linux users tend to be a little more conscious of security matters and know what the implications are when doing anything as root. I expect the user will know the risks if they choose to restart the program as root. I believe in user choice. Thanks again for your replies. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: Elegant way to merge dicts without overwriting keys?
On Thu, May 4, 2017 at 8:23 PM, Malcolm Greene wrote:
> I have a bunch of pickled dicts I would like to merge. I only want to
> merge unique keys but I want to track the keys that are duplicated
> across dicts. Is there a newer dict-like data structure that is fine
> tuned to that use case?
There might be, but I don't keep a close enough eye on things to know.
It's simple enough to just subtract one set of keys from the other.
Simple example:
>>> a = dict(zip(range(0,10), string.lowercase))
>>> a
{0: 'a', 1: 'b', 2: 'c', 3: 'd', 4: 'e', 5: 'f', 6: 'g', 7: 'h', 8: 'i', 9: 'j'}
>>> b = dict(zip(range(5,15), string.uppercase))
>>> a
{0: 'a', 1: 'b', 2: 'c', 3: 'd', 4: 'e', 5: 'f', 6: 'g', 7: 'h', 8: 'i', 9: 'j'}
>>> b
{5: 'A', 6: 'B', 7: 'C', 8: 'D', 9: 'E', 10: 'F', 11: 'G', 12: 'H',
13: 'I', 14: 'J'}
>>> set(b) - set(a)
set([10, 11, 12, 13, 14])
>>> for key in set(b) - set(a):
... a[key] = b[key]
...
>>> a
{0: 'a', 1: 'b', 2: 'c', 3: 'd', 4: 'e', 5: 'f', 6: 'g', 7: 'h', 8:
'i', 9: 'j', 10: 'F', 11: 'G', 12: 'H', 13: 'I', 14: 'J'}
Capture the logic in a function and you're good to go.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Best practice tips for sizing thread/process pools and concurrent futures max_workers?
Looking for best practice tips on how to size thread/process pools or max workers with the concurrent futures module. Are there specific heuristics that can be applied or is this more a manual tuning process based on the run time behavior of a script and the nuances of one's environment? Are there any 3rd party libraries that monitor CPU/core and memory utilization to dynamically tune these values based on system capacity? Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, 05 May 2017 09:00:58 +1000, Cameron Simpson wrote: > On 04May2017 15:03, Wildman wrote: > >>The program installs using the Debian package system (.deb) and an >>entry is created in the Applications Menu. The strange thing is >>that the crash only occurs when the program is run from the menu. >>If I open a terminal and run the program from there, the program >>runs fine. > > And this supports that. > > getlogin is not magic, and can be overused. The Python docs say "Return the > name of the user logged in on the controlling terminal of the process." > Clearly > that will fail. > > When you start from a terminal, your command will have that as its > controlling > terminal unless it has gone out of its way not to. When you start from a > menu, > usually that menu system will not be associated with a terminal. In this case > you need to fall back on other methods of figuring out "who is logged in". What I don't understand is why the program will run from the menu on some Linux distros and not others. I might need to take a closer look at the structure of the .desktop file used to launch my program. Thanks. > You should also _minimise_ the time and work your program does as root. Along > the lines of: > > ... program invoked setuid ... > look up os.getuid() to find the uid of the invoker > read as little as possible of the privileged info (i.e. shadow) as required > os.setuid() BACK TO THE ORIGINAL USER SO YOU ARE NO LONGER ROOT > ... do everything else ... This is interesting. Will do some experimenting. > Part of your problem is that "who is the currently logged in user" is a > nebulous idea. Supposing you were to address the lack of controlling terminal > by seeing who is logged into the console. That is a little trusting. > Supposing > _you_ are logged into the console, running X11. And while so, _I_ ssh into > your > machine and run your program without a controlling terminal. Then your > program > will _mistakenly_ presume the logged in user is _you_ (because, after all, > you're logged in), and report _your_ information to _me_. > > For all that setuid programs have their own security issues, at least they > _know_ who they were invoked by from os.getuid(), without playing insecure > guessing games around "who is logged in". Because the latter is not > equivalent > to "whose information should I access?" > > I hope this points a way forward. > > Personally I would usually resist accessing information not available as the > user, and avoid the need to run as root at all. > > Cheers, > Cameron Simpson I appreciate the advice and will consider it. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Elegant way to merge dicts without overwriting keys?
I have a bunch of pickled dicts I would like to merge. I only want to merge unique keys but I want to track the keys that are duplicated across dicts. Is there a newer dict-like data structure that is fine tuned to that use case? Short of an optimized data structure, my plan is to convert dict keys to sets and compare these sets to determine which keys are unique and can be merged and which keys are dupes and should be tracked in that manner. At a high level, does this sound like a reasonable approach? Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, May 5, 2017 at 9:50 AM, Wildman via Python-list wrote: > I'm afraid that won't work. The user environment is different > than root. A different set of variables. However you have > given me a possible workaround. You can't create a variable > for root unless you are root so that approach is out. But > it might be possible to create the variable for the user > and access it as root. I don't have a lot of experience > using os.environ, but I am going to at it closer. When you start a subprocess, it inherits your environment. So you can create an environment variable for yourself, then start the other process. But read Cameron's cautionary notes and basically just don't do this. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, 05 May 2017 08:31:15 +1000, Chris Angelico wrote: > On Fri, May 5, 2017 at 8:18 AM, Wildman via Python-list > wrote: >> I am using pkexec to restart so $SUDO_USER is not set. For some >> reason sudo, su and su-to-root will freeze the first instance of >> the program and not let it close until the second instance closes. >> I have tried every method I can find to launch them and pkexec >> is the only one that works correctly. >> >> Thanks for the reply. > > Ah, okay. I wonder if you can do the same thing? Just before you > invoke pkexec, create an environment variable with the current user > credentials. Then pkexec back to yourself, and look in the > environment. > > ChrisA I'm afraid that won't work. The user environment is different than root. A different set of variables. However you have given me a possible workaround. You can't create a variable for root unless you are root so that approach is out. But it might be possible to create the variable for the user and access it as root. I don't have a lot of experience using os.environ, but I am going to at it closer. Thanks. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On 04May2017 15:03, Wildman wrote: I tried testing on Mint and Ubuntu and the program would crash. The GUI would appear briefly and disappear. On Ubuntu a crash report was created so I was able to figure out what was going on. It had the traceback and showed that os.getlogin threw an error. This is from the crash report: PythonArgs: ['/opt/linfo-tk/linfo-tk.py'] Traceback: Traceback (most recent call last): File "/opt/linfo-tk/linfo-tk.py", line 1685, in app = Window(root) File "/opt/linfo-tk/linfo-tk.py", line 1393, in __init__ txt = function() File "/opt/linfo-tk/linfo-tk.py", line 316, in userinfo user = os.getlogin() OSError: [Errno 25] Inappropriate ioctl for device This usually means that the program does not have a controlling terminal. The program installs using the Debian package system (.deb) and an entry is created in the Applications Menu. The strange thing is that the crash only occurs when the program is run from the menu. If I open a terminal and run the program from there, the program runs fine. And this supports that. getlogin is not magic, and can be overused. The Python docs say "Return the name of the user logged in on the controlling terminal of the process." Clearly that will fail. When you start from a terminal, your command will have that as its controlling terminal unless it has gone out of its way not to. When you start from a menu, usually that menu system will not be associated with a terminal. In this case you need to fall back on other methods of figuring out "who is logged in". I found a little info on the web about this but it was not clear whether it is a bug in Linux or a bug in the os module. I also found a couple of work-arounds but neither of them will work for my purposes. user = pwd.getpwuid(os.getuid())[0] user = getpass.getuser() I will try to explain... The program reports system information based on the user's name. Things such as passwd, groups and shadow info. However, the program must have elevated privileges to get the shadow info so the program has the option to 'restart as root' so the shadow information will be obtainable. If the program is restarting as root, the work-arounds report the user as 'root'. The "shadow" information is normally concealed for good reason. I appreciate that you're trying to only report that information for the current user, but you should consider whether you should report it at all. Personally I would be reluctant to write a program that "restarts as root"; it feels like a tool where a bug would lead easily to privilege escalation - that the calling user (not root, and from root's point of view untrustworthy) might get it to perform extra tasks beyond your plan AS ROOT. Risky. Is there a way to get the actual user name or is there a fix or a better work-around for the os.getlogin() function? The standard way is not to "restart as root", but to write a setuid program. It still has all the pitfalls of any program running as root (the change for bugs to let the calling user do something they should not be allowed to do), but you can examine the value from os.getuid(): it will be the _calling_ user, while os.geteuid() will be the effective user (root in your case). Then the workaround will be effective. You should also _minimise_ the time and work your program does as root. Along the lines of: ... program invoked setuid ... look up os.getuid() to find the uid of the invoker read as little as possible of the privileged info (i.e. shadow) as required os.setuid() BACK TO THE ORIGINAL USER SO YOU ARE NO LONGER ROOT ... do everything else ... Part of your problem is that "who is the currently logged in user" is a nebulous idea. Supposing you were to address the lack of controlling terminal by seeing who is logged into the console. That is a little trusting. Supposing _you_ are logged into the console, running X11. And while so, _I_ ssh into your machine and run your program without a controlling terminal. Then your program will _mistakenly_ presume the logged in user is _you_ (because, after all, you're logged in), and report _your_ information to _me_. For all that setuid programs have their own security issues, at least they _know_ who they were invoked by from os.getuid(), without playing insecure guessing games around "who is logged in". Because the latter is not equivalent to "whose information should I access?" I hope this points a way forward. Personally I would usually resist accessing information not available as the user, and avoid the need to run as root at all. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, May 5, 2017 at 8:18 AM, Wildman via Python-list wrote: > I am using pkexec to restart so $SUDO_USER is not set. For some > reason sudo, su and su-to-root will freeze the first instance of > the program and not let it close until the second instance closes. > I have tried every method I can find to launch them and pkexec > is the only one that works correctly. > > Thanks for the reply. Ah, okay. I wonder if you can do the same thing? Just before you invoke pkexec, create an environment variable with the current user credentials. Then pkexec back to yourself, and look in the environment. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, 05 May 2017 07:46:32 +1000, Chris Angelico wrote: > On Fri, May 5, 2017 at 6:03 AM, Wildman via Python-list > wrote: >> I will try to explain... >> The program reports system information based on the user's name. >> Things such as passwd, groups and shadow info. However, the >> program must have elevated privileges to get the shadow info so >> the program has the option to 'restart as root' so the shadow >> information will be obtainable. >> >> If the program is restarting as root, the work-arounds report >> the user as 'root'. Then the system information for passwd, >> groups and shadow will be reported for 'root' and not the >> user that ran the program. The actual user name that ran >> the program is needed for the program to report correct >> information. >> >> It seems that only os.getlogin() reports the true user name no >> matter if the program is run as a normal user or restarted as >> root. >> >> Is there a way to get the actual user name or is there a fix >> or a better work-around for the os.getlogin() function? > > That depends on exactly how the program "restarts as root". One very > common way to do this is to invoke itself through sudo(1). If that's > how you're flipping yourself to root, check os.environ["SUDO_USER"] or > os.environ["SUDO_UID"], both of which will be set by sudo before it > invokes the program. > > ChrisA I am using pkexec to restart so $SUDO_USER is not set. For some reason sudo, su and su-to-root will freeze the first instance of the program and not let it close until the second instance closes. I have tried every method I can find to launch them and pkexec is the only one that works correctly. Thanks for the reply. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: os.getlogin() Error
On Fri, May 5, 2017 at 6:03 AM, Wildman via Python-list wrote: > I will try to explain... > The program reports system information based on the user's name. > Things such as passwd, groups and shadow info. However, the > program must have elevated privileges to get the shadow info so > the program has the option to 'restart as root' so the shadow > information will be obtainable. > > If the program is restarting as root, the work-arounds report > the user as 'root'. Then the system information for passwd, > groups and shadow will be reported for 'root' and not the > user that ran the program. The actual user name that ran > the program is needed for the program to report correct > information. > > It seems that only os.getlogin() reports the true user name no > matter if the program is run as a normal user or restarted as > root. > > Is there a way to get the actual user name or is there a fix > or a better work-around for the os.getlogin() function? That depends on exactly how the program "restarts as root". One very common way to do this is to invoke itself through sudo(1). If that's how you're flipping yourself to root, check os.environ["SUDO_USER"] or os.environ["SUDO_UID"], both of which will be set by sudo before it invokes the program. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
os.getlogin() Error
I wrote a Linux only GUI program using Tk that reports various system information using a tabbed Notebook. I have tested the program on Debian, SoldyX and MX-15 and the program runs perfectly. I tried testing on Mint and Ubuntu and the program would crash. The GUI would appear briefly and disappear. On Ubuntu a crash report was created so I was able to figure out what was going on. It had the traceback and showed that os.getlogin threw an error. This is from the crash report: PythonArgs: ['/opt/linfo-tk/linfo-tk.py'] Traceback: Traceback (most recent call last): File "/opt/linfo-tk/linfo-tk.py", line 1685, in app = Window(root) File "/opt/linfo-tk/linfo-tk.py", line 1393, in __init__ txt = function() File "/opt/linfo-tk/linfo-tk.py", line 316, in userinfo user = os.getlogin() OSError: [Errno 25] Inappropriate ioctl for device The program installs using the Debian package system (.deb) and an entry is created in the Applications Menu. The strange thing is that the crash only occurs when the program is run from the menu. If I open a terminal and run the program from there, the program runs fine. I found a little info on the web about this but it was not clear whether it is a bug in Linux or a bug in the os module. I also found a couple of work-arounds but neither of them will work for my purposes. user = pwd.getpwuid(os.getuid())[0] user = getpass.getuser() I will try to explain... The program reports system information based on the user's name. Things such as passwd, groups and shadow info. However, the program must have elevated privileges to get the shadow info so the program has the option to 'restart as root' so the shadow information will be obtainable. If the program is restarting as root, the work-arounds report the user as 'root'. Then the system information for passwd, groups and shadow will be reported for 'root' and not the user that ran the program. The actual user name that ran the program is needed for the program to report correct information. It seems that only os.getlogin() reports the true user name no matter if the program is run as a normal user or restarted as root. Is there a way to get the actual user name or is there a fix or a better work-around for the os.getlogin() function? -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: Promiscuous ports under Linux
On 2017-05-04, Peter Pearson wrote: > I'm curious to survey all my LAN traffic in various ways, and it seems > likely that I will see phenomena that I don't understand, and focussing > in on those phenomena is likely to require more flexible filtering > than Wireshark can provide. I expect to leave this process running for > maybe 24 hours at a stretch, maybe longer, with real-time alerts when > interesting things occur. You can libpcap (which is what wireshark uses on Linux) to deal with the details of capturing the packets and do the analysis in Python. > Maybe Wireshark can do everything I'll ever need to do, but it seems > so complicated, and Python seems so simple . . . I've been using pylibpcap for yonks, and have no complaints. https://sourceforge.net/projects/pylibpcap/ Another advantage of pylibpcap is that you can used it to read files saved by wireshark or tcpdump. -- Grant Edwards grant.b.edwardsYow! Somewhere in DOWNTOWN at BURBANK a prostitute is gmail.comOVERCOOKING a LAMB CHOP!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Promiscuous ports under Linux
On Thu, 04 May 2017 10:26:45 GMT, alister wrote: > On Wed, 03 May 2017 23:57:49 +, Peter Pearson wrote: > >> Cobbling together a minimalist ethernet-sniffing program, I was hoping >> to use this simple mechanism for setting the socket to "promiscuous >> mode" (to see all traffic going past, instead of just traffic addressed >> to my machine): >> >> s.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON) >> >> Unfortunately, it seems that that mechanism is available under Windows >> but not under Linux. Googling around for Linux equivalents, I found >> only very contorted solutions, and concluded that maybe this lacuna >> persists because Linux users find it convenient to invoke promiscuous >> mode from the command line, instead: >> >> $ sudo ip link set eth0 promisc on $ netstat -i# (Verify >> that the P flag is set.) >> >> This somehow fails: my sniffer continues to see only broadcasts, >> but if I run dumpcap at the same time, dumpcap captures lots of traffic. >> >> So my question is now two questions: >> >> . Is it true that going permiscuous under Linux must be somewhat ugly? >>(It's OK if it is, I'll just copy the ugly code and get moving >>again.) >> >> . Why doesn't the command-line "promisc on" work? (Granted, this is >>maybe a Linux question.) >> >> Thanks. > > any particular reason why you wish to re-invent this particular wheel > when wireshark is freely available (& the de-facto tool of choice for > most network engineers) I'm curious to survey all my LAN traffic in various ways, and it seems likely that I will see phenomena that I don't understand, and focussing in on those phenomena is likely to require more flexible filtering than Wireshark can provide. I expect to leave this process running for maybe 24 hours at a stretch, maybe longer, with real-time alerts when interesting things occur. Maybe Wireshark can do everything I'll ever need to do, but it seems so complicated, and Python seems so simple . . . -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: __getattribute__'s error is not available in __getattr__
Thank you Ethan and Chris for the tips. I may be able to adapt that decorator for my use cases -- I hadn't thought of using something like that. Ethan, I'll drop a note over at Python Ideas too with some details about this. Thanks for your help, Jason On Tue, May 2, 2017 at 9:47 PM, Chris Angelico wrote: > On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote: > > Until then Chris' decorator is probably the easiest work around -- but > you > > should only catch AttributeError, not everything. > > It does. (Or rather, it catches only those exception(s) listed as > parameters.) Any other exceptions pass through unchanged. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Problems
On Thu, May 4, 2017 at 4:42 AM, aohK euqsarraT wrote: > I have been using pycharm + python 3.6 for a year and then i updated > pycharm, that was when things became a super buggy mess. I tried to > reinstall everything from scratch but the python installation keeps having > the previous wrong paths that pycharm and python 3.6 are not connected, how > do i make my computer forget all these things and reinstall with all things > automatically work together like the very first time i installed it? (Just > like my other laptop that i just have to click "next" and tick the > recommended sections then everything is in its place). Thanks! > -- > https://mail.python.org/mailman/listinfo/python-list > This is soemthing you should contact Pycharm Support about. There is probably a configuration option under preferences to point Pycharm at your Python executable. I usually set this up with a virtualenv for each project. This link looks like it could be helpful: https://www.jetbrains.com/help/pycharm/2017.1/configuring-python-interpreter-for-a-project.html Also, when selecting an interpreter for a new project or changing the interpreter for an existing project, you don't have to choose from the dropdown. You can manually enter a path as well. Hope this helps. -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeVar single constraint not allowed, why?
On Wed, 3 May 2017 at 18:36 Gregory Ewing wrote: > Ned Batchelder wrote: > > Couldn't you simply annotate it as ": type", without using a TypeVar? > > Not if you want to constrain two types to be the same type. > > Exactly! It would be a lot more expressive to write something like (with Type assumed imported from typing module): def func(a: type, b: type) -> Tuple[Type(a), Type(b)]: ... This will not work because a and b are not globals. I could use strings but this is a hack / language wart as far as I'm concerned (the language should be extended so we don't have to resort to a lowly string). I suppose I could do: def func(a: type, b: type) -> Tuple[TypeVar['a'], TypeVar['b']]: ... but this is not pythonic (not clean, simple), and too easy to have typo. Same with forward declarations, where a class references itself in an annotation: we should not have to resort to a string to express this, very clunky and hacky. > -- > Greg > -- > https://mail.python.org/mailman/listinfo/python-list > -- Oliver My StackOverflow contributions My CodeProject articles My Github projects My SourceForget.net projects -- https://mail.python.org/mailman/listinfo/python-list
Re: Python package to accept payments in Internet
Gregory Ewing wrote: > Victor Porton wrote: >> You carp with words, finding a problem where there is no real problem, >> just words (I mean the word "hack") which sound like a problem. > > Words are important. The very fact that it sounds like a > problem *is* a problem if you're trying to persuade people > to use your software, especially something as critical as > a payment system. Comments like that are going to make > people wonder what other shortcuts have been taken > elsewhere in the code. > > We're not criticising the code so much as suggesting you > re-word the comment. Something like "This code only > provides a subset of the possible functionality, for > something more comprehensive see..." would be a lot > better. Thank you. I've changed the wording as you suggested. -- Victor Porton - http://portonvictor.org -- https://mail.python.org/mailman/listinfo/python-list
Problems
I have been using pycharm + python 3.6 for a year and then i updated pycharm, that was when things became a super buggy mess. I tried to reinstall everything from scratch but the python installation keeps having the previous wrong paths that pycharm and python 3.6 are not connected, how do i make my computer forget all these things and reinstall with all things automatically work together like the very first time i installed it? (Just like my other laptop that i just have to click "next" and tick the recommended sections then everything is in its place). Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Promiscuous ports under Linux
On Thu, 04 May 2017 14:11:04 +0300, Marko Rauhamaa wrote: > alister : > >> On Wed, 03 May 2017 23:57:49 +, Peter Pearson wrote: >> >>> Cobbling together a minimalist ethernet-sniffing program, I was hoping >>> to use this simple mechanism for setting the socket to "promiscuous >>> mode" (to see all traffic going past, instead of just traffic >>> addressed to my machine): >> >> [...] >> >> any particular reason why you wish to re-invent this particular wheel >> when wireshark is freely available (& the de-facto tool of choice for >> most network engineers) > > There are a million plausible reasons. "Just because" is among the > noblest of them. > > Your question has the ring of: Why do you want to compose music when you > can simply turn on the radio? > > > Marko not at all, it was simple curiosity. I have recreated man wheels "just because" as it is a great way to learn but it is important to know that it is probably not the best solution. (likewise if you have heard my guitar playing/karaoke you would agree that turning on the radio is preferred) -- Pereant, inquit, qui ante nos nostra dixerunt. [Confound those who have said our remarks before us.] or [May they perish who have expressed our bright ideas before us.] -- Aelius Donatus -- https://mail.python.org/mailman/listinfo/python-list
Need SpiffWorkflow el6 rpm file.
Hi, I am trying to find SpiffWorkflow compatible to el6 rpm file. Please suggest me where am I get this. @Thanks in advance -- https://mail.python.org/mailman/listinfo/python-list
Re: Promiscuous ports under Linux
alister : > On Wed, 03 May 2017 23:57:49 +, Peter Pearson wrote: > >> Cobbling together a minimalist ethernet-sniffing program, I was >> hoping to use this simple mechanism for setting the socket to >> "promiscuous mode" (to see all traffic going past, instead of just >> traffic addressed to my machine): > > [...] > > any particular reason why you wish to re-invent this particular wheel > when wireshark is freely available (& the de-facto tool of choice for > most network engineers) There are a million plausible reasons. "Just because" is among the noblest of them. Your question has the ring of: Why do you want to compose music when you can simply turn on the radio? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Promiscuous ports under Linux
On Wed, 03 May 2017 23:57:49 +, Peter Pearson wrote: > Cobbling together a minimalist ethernet-sniffing program, I was hoping > to use this simple mechanism for setting the socket to "promiscuous > mode" (to see all traffic going past, instead of just traffic addressed > to my machine): > > s.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON) > > Unfortunately, it seems that that mechanism is available under Windows > but not under Linux. Googling around for Linux equivalents, I found > only very contorted solutions, and concluded that maybe this lacuna > persists because Linux users find it convenient to invoke promiscuous > mode from the command line, instead: > > $ sudo ip link set eth0 promisc on $ netstat -i# (Verify > that the P flag is set.) > > This somehow fails: my sniffer continues to see only broadcasts, > but if I run dumpcap at the same time, dumpcap captures lots of traffic. > > So my question is now two questions: > > . Is it true that going permiscuous under Linux must be somewhat ugly? >(It's OK if it is, I'll just copy the ugly code and get moving >again.) > > . Why doesn't the command-line "promisc on" work? (Granted, this is >maybe a Linux question.) > > Thanks. any particular reason why you wish to re-invent this particular wheel when wireshark is freely available (& the de-facto tool of choice for most network engineers) -- Come quickly, I am tasting stars! -- Dom Perignon, upon discovering champagne. -- https://mail.python.org/mailman/listinfo/python-list
