Re: Logitech C922 Video Issues
did you sysctl kern.video.record=1 ? On Tue, Dec 20, 2022 at 6:42 PM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyn...@orthanc.ca> wrote: > I have a C922 wired up to a mid-2014 Mac Mini. The system sees the > camera, /dev/video responds as expected, but when I run video(1) I > just get a window with a solid green background. > > The camera works with MacOS, so I know the hardware is good, and > when I run the command the white "on the air" LEDs light up on the > camera. I have monkeyed around with different size settings, tried > poking the encoding settings, etc., to no avail. At this point, > I'm stumped. Anyone have any ideas? > > : lyn...@hqmac24.bitsea.ca:/home/lyndon; dmesg|grep video > acpivideo0 at acpi0: IGPU > acpivideo0 at acpi0: IGPU > uvideo0 at uhub0 port 8 configuration 1 interface 0 "Logitech C922 Pro > Stream Webcam" rev 2.00/0.16 addr 10 > video0 at uvideo0 > : r...@hqmac24.bitsea.ca:/home/lyndon; video -v > video device /dev/video: > encodings: yuy2 > frame sizes (width x height, in pixels) and rates (in frames per second): > 160x90: 30, 24, 20, 15, 10, 7, 5 > 160x120: 30, 24, 20, 15, 10, 7, 5 > 176x144: 30, 24, 20, 15, 10, 7, 5 > 320x180: 30, 24, 20, 15, 10, 7, 5 > 320x240: 30, 24, 20, 15, 10, 7, 5 > 352x288: 30, 24, 20, 15, 10, 7, 5 > 432x240: 30, 24, 20, 15, 10, 7, 5 > 640x360: 30, 24, 20, 15, 10, 7, 5 > 640x480: 30, 24, 20, 15, 10, 7, 5 > 800x448: 30, 24, 20, 15, 10, 7, 5 > 800x600: 24, 20, 15, 10, 7, 5 > 864x480: 24, 20, 15, 10, 7, 5 > 960x720: 15, 10, 7, 5 > 1024x576: 15, 10, 7, 5 > 1280x720: 10, 7, 5 > 1600x896: 7, 5 > 1920x1080: 5 > controls: brightness, contrast, saturation, gain, sharpness, > white_balance_temperature, backlight_compensation > Xv adaptor 0, GLAMOR Textured Video: > encodings: yv12 > max size: 3840x2160 > using yuy2 encoding > using frame size 640x480 (614400 bytes) > using default frame rate > run time: 13.795492 seconds > frames grabbed: 209 > frames played: 208 > played fps: 15.004902 > : r...@hqmac24.bitsea.ca:/home/lyndon; > > --lyndon > >
Logitech C922 Video Issues
I have a C922 wired up to a mid-2014 Mac Mini. The system sees the camera, /dev/video responds as expected, but when I run video(1) I just get a window with a solid green background. The camera works with MacOS, so I know the hardware is good, and when I run the command the white "on the air" LEDs light up on the camera. I have monkeyed around with different size settings, tried poking the encoding settings, etc., to no avail. At this point, I'm stumped. Anyone have any ideas? : lyn...@hqmac24.bitsea.ca:/home/lyndon; dmesg|grep video acpivideo0 at acpi0: IGPU acpivideo0 at acpi0: IGPU uvideo0 at uhub0 port 8 configuration 1 interface 0 "Logitech C922 Pro Stream Webcam" rev 2.00/0.16 addr 10 video0 at uvideo0 : r...@hqmac24.bitsea.ca:/home/lyndon; video -v video device /dev/video: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 160x90: 30, 24, 20, 15, 10, 7, 5 160x120: 30, 24, 20, 15, 10, 7, 5 176x144: 30, 24, 20, 15, 10, 7, 5 320x180: 30, 24, 20, 15, 10, 7, 5 320x240: 30, 24, 20, 15, 10, 7, 5 352x288: 30, 24, 20, 15, 10, 7, 5 432x240: 30, 24, 20, 15, 10, 7, 5 640x360: 30, 24, 20, 15, 10, 7, 5 640x480: 30, 24, 20, 15, 10, 7, 5 800x448: 30, 24, 20, 15, 10, 7, 5 800x600: 24, 20, 15, 10, 7, 5 864x480: 24, 20, 15, 10, 7, 5 960x720: 15, 10, 7, 5 1024x576: 15, 10, 7, 5 1280x720: 10, 7, 5 1600x896: 7, 5 1920x1080: 5 controls: brightness, contrast, saturation, gain, sharpness, white_balance_temperature, backlight_compensation Xv adaptor 0, GLAMOR Textured Video: encodings: yv12 max size: 3840x2160 using yuy2 encoding using frame size 640x480 (614400 bytes) using default frame rate run time: 13.795492 seconds frames grabbed: 209 frames played: 208 played fps: 15.004902 : r...@hqmac24.bitsea.ca:/home/lyndon; --lyndon
Re: Guide for Configuring python(1) with httpd(8)
On Tue, Dec 20, 2022 at 02:01:03PM +, indivC wrote: > Crystal, > > I really appreciate the detailed explanations > and step by step instructions. > I was able to follow everything without a problem > and was able to finally access the python file from a web browser. Glad you've got it working! > On Monday, December 19th, 2022 at 11:07 AM, Crystal Kolipe > wrote: > > > # mkdir /var/www/usr/local/lib/pyton3.9 > > # mkdir /var/www/usr/local/include/pyton3.9 > > A slight correction to the lines above > in case anyone comes across this in the future. > The above lines should be: > mkdir -p /var/www/usr/local/lib/python3.9 > mkdir -p /var/www/usr/local/include/python3.9 Yes, you're right, you need to make the intermediate directories too. > > The /var/www/usr/local/lib path is not being searched for dynamic > > libraries when you try to run the python interpreter within the > > chroot. The easiest way to 'make it work' is to move the files > > you just copied to /var/www/usr/local/lib/ to /var/www/usr/lib/ > > instead. > > I think the first sentence makes sense to me. > While trying to search for a solution to the 'ld.so' error, > a lot of the solutions recommended two possible solutions. > The first was to add '/var/www/usr/local/lib' > to the library search path with > 'export LD_LIBRARY_PATH=/usr/lib:/var/www/usr/local/lib'. > The second was to attempt the same thing with > 'ldconfig /var/www/usr/local/lib'. > Neither of these seemed to work, so not sure why. It doesn't make any sense to add a path beginning with /var/www to the library search path from outside the chroot. By doing that, instead of allowing programs within the chroot to search the additional directory or directories, you are telling programs outside the chroot that they can do so. Obviously you will never have a program running outside the chroot that needs to load libraries from /var/www/...anything... Within the chroot, the path would be /usr/local/lib anyway, without the leading /var/www, and if you want to add that path to the library search path within the chroot, then you can run lconfig from within the chroot: # mkdir /var/www/sbin # mkdir -p /var/www/var/run # cp /sbin/ldconfig /var/www/sbin/ # chroot /var/www # sbin/ldconfig /usr/local/lib All this is doing is creating a /var/www/var/run/ld.so.hints file. > Also, I don't really understand why your solution worked. Because /usr/lib is always searched, unless you take specific steps to exclude it. On a normal system with hundreds or thousands of libraries, you probably wouldn't want everything in one directory. But a chroot environment is intended to be minimalist anyway, so it's really a matter of personal preference whether you create a /usr/local/lib directory for non-system libraries or not. > I understand why putting python(1) in chroot is a bad idea. > Therefore, what are the other possible options? Use FastCGI :-) This changes everything. Your python program now runs continuously instead of being launched repeatedly by the webserver for each incoming request. It communicates with the webserver using a socket, (usually a local socket), using the FastCGI protocol. This means that your program does not need to, (and should not), run within the webserver's chroot. It might run in it's own chroot, and it might also use other security features of OpenBSD such as unveil and pledge. It can do this _entirely separately_ from anything that httpd does. In this way, if your program is compromised, it does not have direct access to the memory space of the webserver, so it cannot change the contents of variables, run arbitrary code in the scope of httpd, etc, etc. It's also usually better for performance. Consider, for example, if your program reads a large database when it starts. The way you have things set up at the moment, it's going to be doing that read for every single request. With a single long-running invocation, which is what you usually have when using FastCGI, the database only needs to be read once. And of course you don't have the complicated set up of the chroot to deal with.
Alpine 2.26 on OpenBSD 7.2
I forgot to put the subject line. See my post below. Terrible to use web-mail ... 2022-12-20 16:28 GMT, Rodrigo Readi : > Did someone manage to build alpine mail 2.26 with libressl? > With what configuration options? > > Here is the source: https://alpineapp.email > > The package has 2.25, but that is not enough for google xoauth2. > > I managed to build it with openssl, but I always get failure validating > certs, no idea why. > > Thanks for any hint! > Rodrigo >
[no subject]
Did someone manage to build alpine mail 2.26 with libressl? With what configuration options? Here is the source: https://alpineapp.email The package has 2.25, but that is not enough for google xoauth2. I managed to build it with openssl, but I always get failure validating certs, no idea why. Thanks for any hint! Rodrigo
Re: Guide for Configuring python(1) with httpd(8)
Crystal, I really appreciate the detailed explanations and step by step instructions. I was able to follow everything without a problem and was able to finally access the python file from a web browser. On Monday, December 19th, 2022 at 11:07 AM, Crystal Kolipe wrote: > # mkdir /var/www/usr/local/lib/pyton3.9 > # mkdir /var/www/usr/local/include/pyton3.9 A slight correction to the lines above in case anyone comes across this in the future. The above lines should be: mkdir -p /var/www/usr/local/lib/python3.9 mkdir -p /var/www/usr/local/include/python3.9 > The /var/www/usr/local/lib path is not being searched for dynamic > libraries when you try to run the python interpreter within the > chroot. The easiest way to 'make it work' is to move the files > you just copied to /var/www/usr/local/lib/ to /var/www/usr/lib/ > instead. I think the first sentence makes sense to me. While trying to search for a solution to the 'ld.so' error, a lot of the solutions recommended two possible solutions. The first was to add '/var/www/usr/local/lib' to the library search path with 'export LD_LIBRARY_PATH=/usr/lib:/var/www/usr/local/lib'. The second was to attempt the same thing with 'ldconfig /var/www/usr/local/lib'. Neither of these seemed to work, so not sure why. Also, I don't really understand why your solution worked. > The first thing to understand is that there are several ways to > do what you want to do. Quite a lot of different ways, actually. > That's ONE way of doing it. Definitely NOT the best way for a > real application, but if you're just learning this then it's > probably the easiest^Wleast difficult way in. > Putting python in the chroot is ONE way of doing it. > > It's not the best way in general. But it might be the best way for > you, if you're trying to get an introduction to doing these things. I understand why putting python(1) in chroot is a bad idea. Therefore, what are the other possible options? When I was searching online, I couldn't find anything that didn't involve moving python(1) into chroot, so I'm not sure how to even find another possible solution, let alone a list of them analyzing the pros and cons of each. Again, I really appreciate your help. With it working now, I can start writing some python web apps. Just to be clear, this will not be on a production machine. It's on a non-networked machine that I'm just using to learn that has a web browser installed. However, even though my problem has been solved, I'd like to understand the proper way to configure this.
HP Proliant ML350 Generation9 (Gen9) E5-2620v4 on OpenBSD
Hello, Is HP Proliant ML350 Generation9 (Gen9) E5-2620v4 suited for OpenBSD? If so, does it run stably? Regards Kihaguru.
7.2: snmp mibtree command broken
Hi, Since the release of OpenBSD 7.2, snmp mibtree is broken: > root@host:~# snmp mibtree > snmp: No securityName specified Greetings, Matthias -- genua GmbH Domagkstraße 7, 85551 Kirchheim bei München T +49 89 991950-0, F -999, www.genua.de Geschäftsführer: Matthias Ochs, Marc Tesch Amtsgericht München HRB 98238 genua ist ein Unternehmen der Bundesdruckerei-Gruppe. smime.p7s Description: S/MIME cryptographic signature
