Slight Confusion with ntpd(8)

2022-11-05 Thread indivC
I'm a little confused with the man page for ntpd. 

For the '-n' flag, it says:
'Configtest mode. Only check the configuration file for validity.'.
I have no problem with this and understand it. 

However, the section below that, which is still under '-n', says:
'ntpd will stay in the foreground for up to 15 seconds
waiting for one of the configured NTP servers to reply.'.

The second section seems to contradict the first, in my opinion.
If '-n' is only checking the configuration for validity,
then contacting an NTP server would be outside the scope
of file validation. 

Any clarity on this would be helpful. Thanks.



ntp(d) on Boot Behavior

2022-11-06 Thread indivC
The ntpd man page says the following:
'ntpd will stay for a maximum of 15 seconds in the foreground
and make efforts to verify and correct the time
if constraints are configured and satisfied or
if trusted servers or sensors return results,
and if the clock is not being moved backwards.'.

I could be wrong, but I believe there's another condition
that isn't mentioned. 
As far as I can tell, if the clock is behind less than 60 seconds, 
ntpd will not update the clock. 
In /var/log/daemon, you will see the message:
'cancel settime because offset is negative or close enough'.
The key part being 'close enough'.

I believe the relevant file here is client.c. 
This file pulls the 'AUTO_THRESHOLD' value from ntpd.h.

My question is what's the logic here for having this threshold?
If you have a device that just booted and
it's behind the current time, regardless of the duration,
why not just update the clock to the time from the time server?

I realize this is probably very minuscule,
but it's something I've run into several times.
I've got some devices without real-time clocks. 
Therefore, when I reboot them, they reboot in less than 60 seconds. 
When they come back, the clock isn't synced,
so I manually update the clock to speed up the sync process.

To me, this isn't a functionality problem.
The time is close enough that it shouldn't cause any problems.
However, I see this as more of an administration problem. 
NTP is probably something you want to ensure is working correctly.
Some of the values you might validate are datetime, peers, and clock.
In this scenario, datetime is off by less than 60 seconds,
so you might not even notice it. 
All peers should be valid, so there shouldn't be a problem there.
However, the clock will show as unsynced.
Even with a less than 60 second difference, it can take quite a long
time for the clock to be synced, which would require investigation
from an administration standpoint if you're monitoring this. 

I'm not saying this should be changed, but I just don't understand
the reason for the threshold and given the threshold has required
intervention on my part on several occasions, I'm curious as to the
thought process of this value. Thanks.



Re: ntp(d) on Boot Behavior

2022-11-06 Thread indivC
Stuart,

I am aware that ntpd(8) on boot won't update the clock
if the current time is ahead of the time received
from the time server.
It's in the man page section that I posted in my message.
I personally have never really had an issue there, though.

I'm aware of a variety of ways to resolve the problem.
However, for some reason I hadn't thought of resolving it
by running rdate(8) at boot before ntpd(8).
I've resolved it with running rdate(8) manually 
and also thought about having a remote script run rdate(8) as well.

Would the correct place to do this be in /etc/rc
and rdate(8) should be called right before it says
"echo -n 'starting early daemons:'"?
Or is there a better way of doing this?

Otto,

Something I wasn't thinking about until I read your message 
was how much drift would a non-RTC enabled machine have if offline. 
The answer doesn't seem to be an easy one,
given there are a lot of factors at play. 
My best guess is even with a machine being out of contact
with a time server for several months,
the clock likely wouldn't drift more than 60 seconds. 
I've had old machines that have been offline for a while,
but given they had RTCs, 
I'm assuming that's why I never had any problems related to NTP.
Therefore, I have no threshold for what's normal in regards to drift. 
Out of curiosity, in the future, I'll have to pay more attention
to see how much drift occurred
during the period of time it was offline.

As for the options for resolution,
I'm aware of simply adding RTCs to these machines. 
I'm also aware of changing the monitoring period.
My original thinking was for a server side script
to run rdate(8) depending on the uptime(1) of the machine.
Stuart also mentioned running rdate(8) at boot before ntpd(8) runs.

I appreciate the information. 

--- Original Message ---
On Sunday, November 6th, 2022 at 6:33 PM, Stuart Henderson 
 wrote:


> On 2022-11-06, indivC ind...@proton.me wrote:
> 
> > I could be wrong, but I believe there's another condition
> > that isn't mentioned.
> > As far as I can tell, if the clock is behind less than 60 seconds,
> > ntpd will not update the clock.
> 
> 
> Same if the clock is ahead of NTP time.
> 
> You can ensure that the clock is close by running rdate to set
> against NTP before ntpd starts
> 
> --
> Please keep replies on the mailing list.



netstat(1) Outbound Requests to sunrpc

2022-11-09 Thread indivC
I've started noticing that when I'm using netstat(1), 
I will often see outbound tcp requests for sunrpc (port 111). 
This seems to happen anytime I fail to use the '-n' flag. 
I don't believe this is expected, but I figured I'd ask. 

My understanding is that the '-n' flag will prevent two things:
  1. Translation of port numbers to port names,
 which uses a lookup file (/etc/services)
  2. Translation of IP addresses to domain names

Currently, my OpenBSD machine has only 1 active connection
and that's for NTP. 
I'm using the command 'netstat -f inet'.
Here's what that output looks like:
  Proto  Recv-Q Send-Q  Local Address  Foreign Address
  udp 0  0  192.168.2.3.6145   192.168.1.251.123

In a packet capture, the first two packets are a PTR request
and response for 192.168.2.3.

In the second two packets are an A record request
and response for localhost.home.arpa.
I'm quite confused by this.

'.home.arpa' is the domain I've sent on the OpenBSD machine. 
The machine is not named 'localhost'. 
I realize that localhost refers to the machine itself. 
However, I don't understand why it would send an A record request.
In the netstat(1) output, there are only IPs, not names.
So I don't understand this. 

The next packets in the packet capture are tcp outbound requests 
on port 111 and the requests are destined for 
the IP address of localhost.home.arpa.

These requests are actually trying to go to an external host. 
My understanding is that in a home network environment, 
most ISPs will not return a 'no such name' request.
Instead, they'll return an IP address
that will redirect to you to some landing page of theirs. 

The last two packets in the packet capture are a PTR request
and response for 192.168.1.251. 

Given what I was seeing, I started to wonder what would happen
if an IP wasn't returned for localhost.home.arpa.
I decided to change the DNS server from my ISP's to Cloudflare's. 

When I did this, I still see the same A record request
for localhost.home.arpa. 
However, the request does not return an IP
and no outbound sunrpc requests are attempted. 
But a sunrpc request will still be attempted to the device itself.

I realize that if I always use the '-n' flag,
no sunrpc requests will be attempted nor will any A record requests
for localhost.home.arpa (or any other name).

However, this would mean I could never translate IPs to names. 
I realize I could change my DNS servers, 
which would prevent outbound sunrpc requests, but
that wouldn't explain why sunrpc requests are attempted at all
or the A record request for localost.homa.arpa.
I feel like I have a handle on the problem and solutions. 
However, I'm more interested in some of the behavior 
on OpenBSD's end. 

The two questions I have are:
  1. Why does OpenBSD send an A record request
 for localhost.home.arpa?
  2. Whether or not the A record request returns an IP or not, 
 OpenBSD will attempt a sunrpc request, either to the IP returned
 or to itself. Why is this?

I have no familiarity with sunrpc.
The machine is not running sunrpc. 
Very little on the machine has been changed from the default.
Any information on this is appreciated. Thanks.



AnonCVS CA Issues

2022-11-16 Thread indivC
As far as I can tell, there are issues with the servers below.
I'm unsure if the maintainer is aware, so I figured I'd mention it.

anoncvs1.ca.openbsd.org
I never receive a response from this server.
I end up getting:
'ssh: connect to host anoncvs1.ca.openbsd.org port 22: 
Operation timed out'

I thought the problem was on my end,
thinking maybe it was being blocked by a firewall somewhere. 
I can see outbound SSH traffic, but never anything coming back.
Everything works fine if I switch servers,
so I believe the problem is server side.

anoncvs2.ca.openbsd.org
This domain does not exist,
so pretty easy to determine the issue wasn't on my end.



Re: less prints superfluous characters with --no-init

2022-11-19 Thread indivC
I can't say I understand the technical differences
between 'type' and which(1). 
However, I will mention these points:

  1. There is no man page for 'type', but there is for which(1)
  2. There also appears to be whereis(1). However, I can't speak
 to the differences between this command and the other two. 

--- Original Message ---
On Saturday, November 19th, 2022 at 12:00 AM, Reuben mac Saoidhea 
 wrote:


> you really ought to use `type', not` which',
> in case it is a shell function etc.



Guide for Configuring python(1) with httpd(8)

2022-12-17 Thread indivC
Can anyone provide a guide for this or rough instructions?
I'm running httpd(8) and trying to utilize a python(1) script
with an html file. 
I've got this working using perl(1). 
However, it doesn't work with python(1) when following the same steps. 

My python(1) version is 3.9.15
My OpenBSD version is 7.2 stable. 

First, I use ldd(1) 
to determine what files I need to copy for python(1).
Second, in '/var/www/', 
I create all the folder paths from the ldd(1) output.
Third, I change the ownership of all the folders to be 'www:www'. 
Then, I copy all the files from the ldd(1) output 
into their respective folders. 
Lastly, I change the permissions of all these files to 750. 

At this point, before doing anything with httpd(8), 
I try testing to ensure everything is correct with python(1). 
If I run 'python3 /var/www/htdocs/test/test.py', the script runs.
However, if I run 'chroot /var/www htdocs/test/test.py', 
I get the following error:
"ld.so: python3: can't load library 'libintl.so.7.0'"

'libintl.so.7.0' was one of the files that appeared in ldd(1). 
ldd(1) said the path was '/usr/local/lib/'
and I've got the file copied to '/var/www/usr/local/lib/', 
so I'm unsure why python(1) is saying it can't load it. 

What's a little strange
is if I run the 'chroot' command from above several times in a row, 
I'll see the same error for 'libpython3.9.so.0.0' as well.
ldd(1) also showed this file and I also have it, 
so I'm not really sure what the problem is. 

I've seen some posts indicate
that I also need to copy '/sbin/ldconfig' to '/var/www/'.
Then, run 'chroot /var/www sbin/ldconfig /usr/local/lib/'.
When I do that, I get the following error:
"ldconfig: /var/run/ld.so.hints.: No such file or directory"

In the above error, '' seems to be some pseudorandom value.
If I run the command multiple times, that value changes every time.
For instance, one value I got is 'IkB2akBOKX'.

Maybe the steps to configure this are a little different for python(1)
when compared to perl(1). 
This is why I was hoping someone could provide a link to a guide
or provide some general steps for configuring this. 
Currently, I've just been trying to piece together
what I've been able to find online.

Thanks.



Re: Guide for Configuring python(1) with httpd(8)

2022-12-18 Thread indivC
On Sunday, December 18th, 2022 at 9:04 AM, Omar Polo  wrote:

> instead of asking how to do X so that you can do Y, ask directly how
> to do Y.

I did. The first line of my message was
"Can anyone provide a guide for this or rough instructions?",
which is in reference to the subject
"Guide for Configuring python(1) with httpd(8)".

Did i precede to explain
how I was trying to attempt to accomplish Y with X?
Yes, but I don't see why that would be a problem.
I feel like it's better for users to actually attempt to try
and solve their problems then not to try at all. 

> Why do you need python at all in the chroot? Installing all the
> needed files (and keeping them up-to-date!) manually in a chroot is a
> pain.

I completely agree.
Virtually every solution I've seen online does this.
If there's a better way, I'm all ears.
I think it's reasonable to assume
if someone is attempting to do something
and you believe you have a much better way of accomplishing it,
then share it.
I never said this is the only way to do it
or that this is the only way I want to accomplish this problem.
I just shared what I've been trying to get to work,
which is based on the information I've found online.

> Since httpd speaks fastcgi, why not write some python code that
> accepts the requests over fastcgi? (assuming this is what you're
> trying to do, but you didn't tell.)

I believe that is exactly what I'm trying to do. 
The end goal is to be able access a python(1) file from httpd(8).
My understanding is you have to configure slowcgi(8),
which utilizes fastcgi, within httpd(8).
I've been able to configure that without any problems using perl(1),
but not with python(1).

With python(1), because the problem is occurring
before I even get to httpd(8), I left that out of the message. 
If I attempt to access the python(1) file currently, 
I still see the same 'ld.so' error message I mentioned before.
Therefore, I was trying to leave out httpd(8)
and slowcgi(8) configuration as that isn't where the problem lies. 

As mentioned before, if you have a better solution for this, 
please share.
Any links you can provide for step by step instructions 
or general steps on how to accomplish this would be helpful. 

Thanks.



Re: Guide for Configuring python(1) with httpd(8)

2022-12-18 Thread indivC
On Sunday, December 18th, 2022 at 8:38 AM, Mark Willson 

> This is the script I use to set up python for httpd:

I looked over the script and it seems to do
pretty much what I've already done. 
It copies some additional files that I didn't copy. 

My first attempt was just to copy over the additional files
that I had not previously copied that are in your script. 
This didn't change anything for me. 

I then decided to run your script directly.
I removed the parts in the script
that dealt with touching any folder path with 'run'.
'slowcgi.sock' is in '/var/www/run/'
and I didn't want to mess with it.
Also, it doesn't look like the script does anything with files
in these folders, so it shouldn't matter that I omitted them. 

On the first run, it wasn't able to copy 'libiconv.so.7.0'.
On my system, it's 'libiconv.so.7.1'.
Therefore, I updated that line in the script to 'libiconv.so.*'.
This better matches how all the other lines are in the script.
I'm not sure why this line and the one above it are different.

Then, I ran the script again.
However, I still get the same 'chroot' error:
"ldconfig: /var/run/ld.so.hints.: No such file or directory"

So I'm not sure why I'm getting different results than you.
It's like something is attempting to generate a pseudorandom file
using 'ld.so.hints' as a base.
These pseudorandom filenames do not exist,
but '/var/run/ld.so.hints' does,
so I'm not sure why it doesn't just use that file directly.



Re: Guide for Configuring python(1) with httpd(8)

2022-12-18 Thread indivC
Thanks for all the responses. 
I'll respond to everyone (Omar, Crystal, Stuart, Bodie)
within this message to prevent sending out multiple messages. 

It appears my message was significantly less clear than I thought.
My apologies. 
Let me try again and
then I'll respond directly to messages further down. 

What I'm trying to do is display a python file
that has imbedded HTML within a web browser.
The file is 'hello_world.py' and below are its contents:
  #!/usr/local/bin/python3
  print('Content-type:text/html\n')
  print('')
  print('')
  print('Hello World')
  print('')
  print('\n')

Within a browser, I want to be able to access this file
and see 'Hello World' displayed.
Where does this file need to be placed?
What configuration changes need to be made to make this work?

Currently, httpd(8) is running
and I'm able to access HTML files via a web browser.
I've seen mentions online that I needed to run slowcgi(8)
in order to get this to work, so I did 'rcctl enable slowcgi' and
'rcctl start slowcgi'.
Then, I placed 'hello_world.py' in '/var/www/htdocs/test/'
and then added the 'location' configuration to '/etc/httpd.conf'.
Below is the full 'httpd.conf':
  server "test" {
listen on 10.1.1.1 port 80
root "/htdocs/test"
location "*.py" {
  fastcgi
  root "/htdocs/test"
}
  }

  types {
include "/usr/share/misc/mime.types"
  }

The reason I was messing with python(1) in chroot
was because that's what I was seeing online.
If that doesn't need to be messed with, great.
However, I don't know what I'd need to do to make this work. 

On Sunday, December 18th, 2022 at 11:18 AM, Omar Polo  wrote:

> not exactly, fastcgi is a binary protocol, whereas from what you're
> writing I'm assuming you're trying to run a CGI script written in
> python with slowcgi.
> 
> (this is what I meant with "explain what you're trying to do" as there
> is a big difference between running a python web application and
> running a custom CGI script.)

Sorry. Hopefully what I have at the top of this message
makes it more clear.
I'm guessing the answer is I'm trying to run a python web application,
but honestly, I'm not sure. 
When you say 'custom CGI script', that just confuses me.
I'm assuming that's more backend web development
where data is passed from the server via CGI (slowcgi/fastcgi?)
to python(1).
Whereas python web application
is more of the front end web development
that controls how the page itself looks.
Currently, I'm just trying to load a python file to display content.

> On pypi there is a 'fastcgi' library. 

I'll have to take a look at this.
I didn't think I'd need to install an additional library
if I was just trying to display some HTML content. 

On Sunday, December 18th, 2022 at 11:38 AM, Crystal Kolipe 
 wrote:

> It's probably about one day's work.

What may be one day's worth of work for you may be weeks/months
for me.
I don't forsee this being that easy for me. 

On Sunday, December 18th, 2022 at 1:11 PM, Stuart Henderson 
 wrote:

> Surely the goal is to run some particular software and make it available
> via an httpd(8) frontend and not just run python(1) i.e. the Python 
> interpreter?

Actually, I think this is exactly what I'm trying to do right now.
Maybe it's stupid to do this,
but I figured I'd start just with python.
After getting that to work and understanding it, 
then maybe use additional software with python.
See my original message at the top that hopefully better explains
what I'm trying to do. 

>fastcgi
> is more common with other languages but also possible with Python and
> would often be a better fit than trying to run Python directly in a chroot
> via httpd->fastcgi->slowcgi->python(1).

Any guides, resources, or rough instructions on how to do this?

On Sunday, December 18th, 2022 at 3:21 PM, Bodie  wrote:

> As was already pointed out by others it may be good to know what
> are you trying to achieve actually aka why you are trying to put
> python in chroot. Especially as you said it works with perl fine
> and that one is in base.

Apologies. Hopefully my message at the top is more clear now.



Re: Guide for Configuring python(1) with httpd(8)

2022-12-20 Thread indivC
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.



Re: Guide for Configuring python(1) with httpd(8)

2022-12-23 Thread indivC
--- Original Message ---
On Tuesday, December 20th, 2022 at 6:44 PM, Crystal Kolipe 
 wrote:

If you don't mind, I'd like to respond to some of this later.
I think I better understand some of my confusions,
but I'm not fully there yet.

Currently, I've had no issues displaying content.
I can display HTML from within a python file
and run python code to alter what's displayed in HTML.
All good stuff.

However, the 'cgi' module is giving me trouble that I can't resolve.
It simply won't import without errors.

Why am I trying to import the 'cgi' module?
What I want to do is pass data.
For instance, here's 'test.py':
  #!/usr/local/bin/python3
  
  print ('''

  Name
  
  Submit

  ''')

  print(f"Your name is 'name_goes_here'")

The above is just a simple example that has one input field ('name').
In order to grab the 'name' inputted by the user,
I need to use the 'cgi' module.
The python code above doesn't contain anything
for the 'cgi' module as I can't import it.
I just thought showing an example might avoid any confusion.

As for what's the problem with the 'cgi' module,
below is a test file called 'cgi-test.py':
  #!/usr/local/bin/python3

  import cgi

When I run 'chroot /var/www htdocs/test/cgi-test.py',
I get the below:

File "/usr/local/lib/python3.9/email/header.py", line 14,
 in 
  import binascii
  ImportError: Cannot load specified object

I know, chroot is bad bad.
I think once I can resolve this,
I'll go back through your responses
and attempt to move away from chroot and start using fastcgi.

I tried to troubleshoot the above error,
but I haven't gotten anywhere.
My first thought was where is this module located,
so I ran 'python3' to run the Python Interpreter
and entered the below:
  >>> import binascii
  >>> binascii.__file__
  '/usr/local/lib/python3.9/lib-dynload/binascii.cpython-39.so'

So that's the location of the module.
It is located in the same path within '/var/www/'
and it also has the correct permissions,
but unsure what's the problem with importing it.