Re: socket.makefile & AF_UNIX
>If you're trying to create a Unix socket then mknod() isn't what >you need. You probably want to create a socket and bind() it to >the log file: >filename = 'snort_alert' > s = socket(AF_UNIX, SOCK_DGRAM) > s.bind(filename) Interesting - I tried this with a local test_log and it worked, creating: srwxr-xr-x 1 field users 0 Dec 10 19:26 test_log= which looks like my /dev/log device. >The call to bind() will probably fail if the socket file already >exists, Indeed it does. > If it's binary then you might need to use s.recv(). Makes sense. Thanks Michael. I'd expect socket.makefile is probably less encountered than most aspects of socket (according to google, it sure seemed so!). Jamie -- http://mail.python.org/mailman/listinfo/python-list
socket.makefile & AF_UNIX
I think I'm overlooking something assumed in socket's makefile method.
Googling several hours and digging thru the python reference didn't help - I
think I'm overlooking an assumption between Python and UNIX socket objects
neither is explicitely discussing. I think my mknod
In the makefile operation on socket (pydoc socket.socket.makefile... using
AF_UNIX, allowing you to create a file object to correspond to a socket) I've
got an sample program (goal: open up unix file socket object for snort's
alert_unixsock output mode to dump to. later, take data written into file
object and process) as follows:
###3
#!/usr/bin/python
## socketfile.py
## for socket file object to collect snort data via alert_unixsock output
"""makes file interface to socket. demo application takes data written to file
and prints it."""
from socket import *
import os
FILE = 'snort_alert'
#FILE = '/dev/log'
if not os.path.exists(FILE):
print "Creating file..."
os.mknod(FILE)
s = socket(AF_UNIX, SOCK_DGRAM)
# SOCK_DGRAM for UDP compatibility with /dev/log - errors
# on SOCK_STREAM reference for /dev/log
s.connect(FILE)
f = s.makefile('rw')
while 1:
print "Data: %s" % f.readline(1024)
f.flush()
###3
If I guess correctly, socket.makefile might be wanting to use a block or
character file, which I may not be setting up properly. pydoc on os.mknod
refers to os.makedev which is even sparser on explanation. Part of the reason
for my guess is that:
- permissions on my snort_alert file don't look right:
-rw--- 1 sysadmin users 0 Dec 10 02:58 snort_alert
compared to:
srw-rw-rw- 1 root root 0 Dec 10 01:14 /dev/log=
And when I use /dev/log instead (which exists), it connects to the file object
and runs (though snort does not want to dump to /dev/log and the limitations
of the alert_unixsock output method limit it to /var/log/snort/snort_alert
only). Any thoughts from the socket savvy would be *greatly* appreciated!
Jamie
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 14, Issue 377
On Mon, 29 Nov 2004 16:05:14 -0500, "Eric S. Johansson" <[EMAIL PROTECTED]> wrote: > If I could simply do: py-get twisted And I forgot to mention, the Gentoo 'emerge' tool is actually written in Python, so in a sense, your py-get is already there in Gentoo. From the header of /usr/bin/python: #!/usr/bin/python -O # Copyright 1999-2004 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-src/portage/bin/emerge,v 1.347 2004/10/21 20:54:38 carpaski Exp $ Gentoo is a rather enjoyable distro for Python work. Most Python packages are an emerge away: twisted, zope (including zope3), bsddb, mysql & postgresql interfaces, python-ldap, pyparsing and many others. A few to make Gentoo more enjoyable: 1. standardize on a kernel (e.g. I use hardened-dev-sources for servers and gentoo-dev-sources for workstations - all 2.6 kernels,) This simplifies maintenance and opens up distcc for you (which will be handy if you have a few systems that will be running Gentoo and want to speed up source builds). You'll need a common kernel and gcc version in order to not have distcc issues. 2. read up on USE= flags. It simplifies dependencies significantly, but you want to make sure you're using it to its fullest, not leaving out important options or including everything and the kitchen sink. For instance, if you're not using ipv6, don't bother - including this in your USE= statement will slow down source builds significantly for no benefit (not to mention some bloat and potentially some security issues for unmonitored capabilities e.g. enabling samba USE without discretion). 3. set your ACCEPT_KEYWORDS = 'x86' (assuming intel/x86) to back off minor version builds. of course, if you need bleeding edge packages, you may have to use ~x86. x86 is the "stable" setting. 4. for help, forums.gentoo.org is useful (though the search engine is rather lacking imho) Having started with two 5.25's in 1993, I've been a die-hard user of SLS, Slackware, Redhat, Debian and now Gentoo. You'll hear plenty of distro war stuff and certainly every tool has its pros/cons. For python, if you haven't given Gentoo a look, check it out... Jamie -- http://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 14, Issue 377
On Mon, 29 Nov 2004 16:05:14 -0500, "Eric S. Johansson" <[EMAIL PROTECTED]> wrote: > If I could simply do: py-get twisted or how about 'emerge twisted' works fine for me! When twisted2 comes out, emerge world will catch it for me too. Check out Gentoo at http://www.gentoo.org for more info, or on IRC at #gentoo Jamie Saker "Gentoo bumper sticker: I'd rather be compiling!" -- http://mail.python.org/mailman/listinfo/python-list
