Re: Offline FAQ

[lists]

Thu, 19 Jul 2018 03:57:17 -0700 Ahmed Khanzada 
> Hello,
> 
> I am a programmer with a strong passion for both documentation and offline
> computing. Inspired by 9front, I was wondering if there was any interest
> in porting the currently online-only FAQ to an offline FAQ format that could
> perhaps ship with OpenBSD by default, enabling a user to have a completely
> self-documented operating system without the need for an Internet connection.

Hi Ahmed,

You can be sure you are not the only one.  Yes indeed, there is interest
in having the system include all necessary documentation to use offline,
immediately after the installation every important information included.

The key here is: important to have while all offline reducing ambiguity.
The manuals are also available online, via the man.openbsd.org web site.

> Preferably, this offline FAQ would not be in HTML or anything browser-centric,
> but rather in something like a man format friendly for terminal perusing.

There is absolutely a necessity for getting started manual page for each
section, typically called intro.  I imagine the bits that can not be put
in the respective manual page could be placed in an extra(section) page.

Use the name you think appropriate: book, guide, index, faq, extra, etc.
Then updating to the latest snapshot just gives you the updated manuals.
 
> I would be more than happy to lend my time and efforts to such a project, if
> the community deems it appropriate.

You know.. there is absolutely NOTHING preventing you from making these,
at least in your local copy of the operating system and then ask review.

You could start by reducing to a minimum the "changing" and "extraneous"
nature of these documents moving the bits to their manual pages and then
just again carefully reconsider why still need to have an extra manpage.

Of course, you do otherwise there would be no FAQ, right?  Deep thought.
In my personal opinion, it is important to have a "reference book", YES.

> -- Ahmed Khanzada
> 

Thank you for raising this question I think it is important and welcome,
from both novice and experiences user perspective this would be awesome.

You should also know, if you provide something you must also DO maintain
it over long time, longer than you suppose, otherwise it's worse service
to give something and run away not keeping it relevant than not have it.

Kind regards,
Anton Lazarov

Re: newaliases vs makemap

[Theo de Raadt]

>On Sun, 15 Jul 2018 17:59:58 -0700, Scott Vanderbilt wrote:
>
>> In /etc/mail/aliases, there is the following note:
>>
>> #>>  The program "newaliases" must be run after
>> #>> NOTE >>  this file is updated for any changes to
>> #>>  show through to smtpd.
>
>That is correct.
>
>> Yet the man page for newaliases(8) says:
>>
>> Note: this utility is provided for sendmail compatibility. The 
>> preferred way of rebuilding the database is withmakemap(8) 
>> :
>
>This is bad advices that should be removed.  It is only true if
>using db files for aliases.  When using a flat file for aliases,
>you should use newaliases, which will notify smtpd that the file
>has changed.

I agree completely.  smtpd should stop trying to act like a special
little child.

An interface was copied from sendmail because that is what everyone
knows.  Therefore a program has to exist, which works exactly like
everyone already knows.  Therefore it must not have glitches and
behaviours which cause confusion.  Since the entire reason this
interface was added was *to ease the learning curve and avoid
confusion*.

Re: httpd rewrite, what I'm missing?

[Elias M. Mariani]

Just a breaktrough, but the problem persists:

-
#example of directory that doesn't need to use rewrite.
location match "/themes/(.*)/assets/(.*)" {
request no rewrite
}

#index.php is the entry point of the application and runs the php fastcgi.
location match "index.php" {
fastcgi socket "/run/php-fpm.sock"
}

#all others locations rewrite to /index.php
location match "(.*)" {
request rewrite "/index.php$REQUEST_URI"
}
-

The problem is that when rewriting to index.php in this manner the
links are formatted in the same way as the rewrite, is there a way
apart from "request strip" that I can use to change the $REQUEST_URI
so the fastcgi socket gets the value with the "/index.php" striped ?

cheers.
Elias.

2018-07-17 17:13 GMT-03:00 Elias M. Mariani :
> Hi,
> I'm trying to adapt the rewrite rules of OctoberCMS to httpd.conf to
> avoid using apache-httpd.
>
> Now everything is working ok with this rules:
>
> -
> #example of directory that doesn't need to use rewrite.
> location match "/themes/(.*)/assets/(.*)" {
> request no rewrite
> }
>
> #index.php is the entry point of the application and runs the php fastcgi.
> location match "index.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
>
> #all others locations rewrite to /index.php
> location match "(.*)" {
> request rewrite "/index.php"
> }
> -
>
> But for some reason the URLs are working like this:
> example.com/forums/openbsd
> Works ok, rewrites and everything is OK, but for some reason all the
> links point to:
> example.com/index.php/forums/openbsd
> That also works the same as is the first case.
>
> Now, this URLs are defined by the application, I guess that the
> application understands that the base_url (I made the name up...) is
> example.com/index.php and not example.com ?
>
> Might this be an incompatibility between httpd and apache-httpd?
>
> Cheers.
> Elias.

Re: Offline FAQ

[Ingo Schwarze]

Hi Ahmed,

Ahmed Khanzada wrote on Thu, Jul 19, 2018 at 03:57:17AM -0700:

> I am a programmer with a strong passion for both documentation and
> offline computing.  Inspired by 9front, I was wondering if there was
> any interest in porting the currently online-only FAQ to an offline
> FAQ format that could perhaps ship with OpenBSD by default, enabling
> a user to have a completely self-documented operating system without
> the need for an Internet connection.
> 
> Preferably, this offline FAQ would not be in HTML or anything
> browser-centric, but rather in something like a man format friendly
> for terminal perusing.

I already planned that for years and finally offered one and a half
years ago to do the work of the HTML to mdoc(7) conversion myself
and fully integrate the FAQ into the base system manual pages, as
a new "faq" section alongside the traditional numeric sections.

My arguments were:

 1. Easier maintenance.
No more need to update the FAQ in one big step at release time.
Lower risk to lose patches because everything can be committed
at any time.  Easier for others to contribute because right
now, nobody knows what exactly has already been written for the
next release.

 2. Easier editing.
In particular, mdoc(7) .Xrs and .Sxs are much less cumbersome
to edit than HTML s, and there are a lots of them.
But that applies to almost all markup, even ".Fl x"
is shorter and easier to type than "-x".

 3. FAQs for -current become available, not only with spending
no additional maintenance effort, but even reducing effort.

 4. The FAQ becomes available offline because it can simply
be installed just like the other manuals.

 5. FAQ pages show up in apropos(1).

 6. More expressive markup.
All mdoc(7) macros can be used, not just  and .

 7. Semantic searching.
FAQ pages can be searched for with apropos(1) searches for
specific macro keys.

 8. Normal manual pages can more naturally link back to the FAQ
by simply using .Xr rather than .Lk.

 9. It's always good to have all documentation available in one
place and with one tool: users will less easily miss the
parts they are looking for.

However, the current FAQ maintainers, tj@ and tb@, vetoed the idea
arguing as follows:

 1. They dismissed argument 1, stating they feel it isn't significantly
harder to collect updates non-publicly over time and then commit
them all together at release time than to follow the normal
"only even edit -current" policy used for the source tree at
large, including manual pages.

 2. They dismissed argument 2, stating that they personally know
HTML better than mdoc(7) and expect more users to know HTML
than mdoc(7).

 3. They dismissed argument 3, saying that the FAQ is mainly for
new users (which i disagree with), these mainly run -stable,
and having a -current FAQ would only cause confusion (which
i don't believe either - quite to the contrary, i often see
confusion because people try to use the FAQ with -current).

 4. They dismissed argument 4, saying that they specifically
want to keep the FAQ online-only such that corrections
are instantly visible to users, while offline versions
would retain errors until the next update.

 8. They dismissed argument 8, saying that few manual pages
link to the FAQ in the first place.

There was consensus that arguments 5 to 7 and 9 are relevant, but
they considered them less important than the percieved downsides
in arguments 1 to 4.

Given that i highly appreciate the important work tj@ and tb@ do
on the FAQ, i decided to not do the conversion because no matter
what others may think, the people actually doing the work (in this
case the FAQ maintenance) get to decide how they do it.  And in
this case, they clearly prefer keeping the FAQ separate and in HTML.
So that is what gets done, even though i almost completely fail to
understand the reasons.


> I would be more than happy to lend my time and efforts to such
> a project, if the community deems it appropriate.

Much appreciated, but unfortunately, that is not sufficient to let
the idea become reality at this point in time.  It would be great
if you could start sending patches for whatever issues you find in
both manual pages and in the FAQ, though.

Yours,
  Ingo

Re: Offline FAQ

[Jacqueline Jolicoeur]

On Jul 19 03:57, Ahmed Khanzada wrote:
> Hello,
> 
> I am a programmer with a strong passion for both documentation and offline
> computing. Inspired by 9front, I was wondering if there was any interest
> in porting the currently online-only FAQ to an offline FAQ format that could
> perhaps ship with OpenBSD by default, enabling a user to have a completely
> self-documented operating system without the need for an Internet connection.
> 
> Preferably, this offline FAQ would not be in HTML or anything browser-centric,
> but rather in something like a man format friendly for terminal perusing.
> 
> I would be more than happy to lend my time and efforts to such a project, if
> the community deems it appropriate.
> 
> -- Ahmed Khanzada
> 

Why not simply use cvs and a terminal browser from packages/ports
(w3m, links+, lynx) to view the faq offline?

$ cvs checkout -P www/faq
$ w3m www/faq/index.html

Offline FAQ

[Ahmed Khanzada]

Hello,

I am a programmer with a strong passion for both documentation and offline
computing. Inspired by 9front, I was wondering if there was any interest
in porting the currently online-only FAQ to an offline FAQ format that could
perhaps ship with OpenBSD by default, enabling a user to have a completely
self-documented operating system without the need for an Internet connection.

Preferably, this offline FAQ would not be in HTML or anything browser-centric,
but rather in something like a man format friendly for terminal perusing.

I would be more than happy to lend my time and efforts to such a project, if
the community deems it appropriate.

-- Ahmed Khanzada

Re: cgi issues

[Jacqueline Jolicoeur]

> We have a winner. Thanks for the help. Including compile commands to help
> anyone who may come across this thread.
>
> cc -c -o test.o test.c
> cc -o test -static test.o

or ...

/usr/share/mk/bsd.README

LDSTATIC=   ${STATIC}

Re: rying to get meta-data configured for cloud-image VMM instances

[Ax0n]

On Mon, Jul 16, 2018 at 4:30 PM, Reyk Floeter  wrote:

> https://www.openbsd.org/faq/current.html#r20180613b
>
> I can respond in more details when I’m back online later this week.
>
> Reyk
>
>
Thanks, Reyk. I missed that in the -CURRENT docs. Indeed, this clause seems
to work, as far as httpd starting:

-
server "meta-data" {
listen on 169.254.169.254 port 80
fastcgi socket "/run/httpd.sock"
root  "/"
request strip 1
}
-

I also added an alias of 169.254.168.254 to vether0 (not with
hostname.vether0, just from the command-line) and re-started httpd to see
what happens.

This is what I'm getting from cloud-init now:

 Starting Initial cloud-init job (metadata service crawler)...
[   10.292630] cloud-init[939]: Cloud-init v. 18.2 running 'init' at Thu,
19 Jul 2018 14:22:12 +. Up 5.16 seconds.
[   10.340633] cloud-init[939]: ci-info:
++Net device
info++
[   10.392636] cloud-init[939]: ci-info:
++--+-+---+---+---+
[   10.448639] cloud-init[939]: ci-info: | Device |  Up  |
Address   |  Mask | Scope | Hw-Address|
[   10.504643] cloud-init[939]: ci-info:
++--+-+---+---+---+
[   10.560646] cloud-init[939]: ci-info: | enp0s4 | True |
10.13.37.47 | 255.255.255.0 |   .   | fe:e1:bb:d1:03:a8 |
[   10.620650] cloud-init[939]: ci-info: | enp0s4 | True |
fe80::fce1:bbff:fed1:3a8/64 |   .   |  link | fe:e1:bb:d1:03:a8 |
[   10.676654] cloud-init[939]: ci-info: |   lo   | True |
 127.0.0.1  |   255.0.0.0   |   .   | . |
[   10.728657] cloud-init[939]: ci-info: |   lo   | True |
::1/128   |   .   |  host | . |
[   10.784660] cloud-init[939]: ci-info:
++--+-+---+---+---+
[   10.840664] cloud-init[939]: ci-info: Route
IPv4 info+
[   10.892667] cloud-init[939]: ci-info:
+---+-++---+---+---+
[   10.940670] cloud-init[939]: ci-info: | Route | Destination |  Gateway
|Genmask| Interface | Flags |
[   10.992673] cloud-init[939]: ci-info:
+---+-++---+---+---+
[   11.040676] cloud-init[939]: ci-info: |   0   |   0.0.0.0   | 10.13.37.1
|0.0.0.0|   enp0s4  |   UG  |
[   11.092680] cloud-init[939]: ci-info: |   1   |  10.13.37.0 |  0.0.0.0
| 255.255.255.0 |   enp0s4  |   U   |
[   11.140683] cloud-init[939]: ci-info:
+---+-++---+---+---+
[   11.192686] cloud-init[939]: 2018-07-19 14:22:18,108 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]:
bad status code [404]
[   11.296692] cloud-init[939]: 2018-07-19 14:22:19,112 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]:
bad status code [404]
[   12.300755] cloud-init[939]: 2018-07-19 14:22:20,116 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]:
bad status code [404]
[   13.308818] cloud-init[939]: 2018-07-19 14:22:21,124 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]:
bad status code [404]
[   14.312881] cloud-init[939]: 2018-07-19 14:22:22,128 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [4/120s]:
bad status code [404]
[   15.320944] cloud-init[939]: 2018-07-19 14:22:23,136 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [5/120s]:
bad status code [404]
[   17.329069] cloud-init[939]: 2018-07-19 14:22:25,145 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [7/120s]:
bad status code [404]
[   19.333195] cloud-init[939]: 2018-07-19 14:22:27,149 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [9/120s]:
bad status code [404]
[   21.541333] cloud-init[939]: 2018-07-19 14:22:29,357 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [11/120s]:
bad status code [404]
[   23.545458] cloud-init[939]: 2018-07-19 14:22:31,361 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [13/120s]:
bad status code [404]
[   26.141620] cloud-init[939]: 2018-07-19 14:22:33,957 -
url_helper.py[WARNING]: Calling '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [15/120s]:
bad status code [404]
[   29.145808] cloud-init[939]: 2018-07-19 14:22:36,961 -
url_helper.py[WARNING]: Calling '

Adding New Commands to BGP Looking Glass?

[MonsieurFugu]

Hi OpenBSD forum,

I've recently set up a BGPLG and I've been trying to add "mtrace" to the
drop down command list, but I've been having a bit of trouble getting it to
work and was wondering if anyone could point me in the right direction to
get it working.

I've configured the "bgplg.c" to define and add mtrace, I've gone into the
"bgplg.h" file to add mtrace as a command to the menu, and I've made sure to
copy the mtrace source files into the "/usr/src/usr.bin/bgplg" directory, as
well as the executable (I think its the executable anyway) into the
"/var/www/bin" directory. However even after rebooting and restarting
everything I can't get the mtrace command to appear in the drop down menu. 

I tried my best to follow this walk through process of adding traceroute6
and ping6 to the bgplg
(http://openbsd-archive.7691.n7.nabble.com/Added-commands-for-bgplg-td155767.html),
which is the only source I've found that relates to adding new commands to
the BGPLG menu, but something still isn't working for me. 

If you need specifics I can certainly supply screenshots or code snippets.
It's probably something obvious that I'm just not seeing, but any help would
be greatly appreciated.

Cheers.



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html