pkg_add logs
Hello misc@, I have been looking for the date I last updated qgis. Thanks to this old thread, https://marc.info/?l=openbsd-misc&m=119449610716702&w=2 I could find what I was looking for date using stat(1). However man pkg_add states that "pkg_add will syslog(3) installations and updates by default" I checked my syslog.conf but couldn't find the file where pkg_add logs by default. So here is my newbie question : where would I find pkg_add logs ? Best regards, Damien Thiriet
Re: logs
Re: logs
hey all, is there a similar "logwatch" program as in other linux systems any recommendation? thanks
Re: logs
"Mike F" <[EMAIL PROTECTED]> writes: > is there a similar "logwatch" program as in other linux systems only vaguely remembering logwatch, I think logsentry (in ports and packages) would be something like what you are looking for -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: logs
On Tue, 16 Oct 2007, Mike F wrote: > is there a similar "logwatch" program as in other linux systems > > any recommendation? See security/logsurfer and security/logsentry. Maybe others too. Jeremy C. Reed
Re: logs
On Tue, Oct 16, 2007 at 05:55:03PM +, Mike F wrote: > > is there a similar "logwatch" program as in other linux systems What do you mean by _other_ linux systems. This isn't a linux system. :))) Doug.
Re: logs
On Tuesday, 16.10.2007 at 17:55 +, Mike F wrote: > hey all, > > is there a similar "logwatch" program as in other linux systems logsentry is what you want. OpenBSD's logsentry *is* logcheck, just renamed. Dave. -- Dave Ewart - [EMAIL PROTECTED] - jabber: [EMAIL PROTECTED] - freenode: davee All email from me is now digitally signed, key from http://www.sungate.co.uk/ Fingerprint: AEC5 9360 0A35 7F66 66E9 82E4 9E10 6769 CD28 DA92
Re: logs
On Tue, 16 Oct 2007 17:55:03 +, Mike F wrote: > is there a similar "logwatch" program as in other linux systems There is logwatch. Just download and install ... Uwe
Re: logs
On Tue, Oct 16, 2007 at 05:55:03PM +, Mike F wrote: > hey all, > > is there a similar "logwatch" program as in other linux systems > > any recommendation? SEC (sysutils/sec) is pretty good, if a little more complex. Joachim -- TFMotD: buffercache, bread, breadn, bwrite, bawrite, bdwrite, getblk, geteblk, incore, allocbuf, brelse, biodone, biowait (9) - buffer cache interfaces
rotating apache logs
Hi. What is the best way to rotate apache logs on OpenBSD? Ideally I would like to create a new one at the beginning of each month. I searched my system for logrotate and could not find it. Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Managing PF logs
Hi all, I am thinking about how could be the best option to inject PF logs in Elasticsearch (or any similar platform). If I am not wrong, some years ago there is an option using a shell wrapper to store all pf logs in ASCII format and redirect all of them to a central syslog server (published in PF FAQ). More or less it is what I am looking for. But maybe exists another best option in nowadays. Any ideas? Tips? Regards, C. L. Martinez
sysupgrade failure logs
Hello folks, I am having an issue with sysupgrade and I have had trouble finding the source of the problem so I hope someone here might be able and willing to point me in the right direction. I have 6 small systems running OpenBSD -current and I have a basic script which upgrades to the latest snapshot weekly. The systems are all relatively similar. Three are the exact same piece of hardware, two are slightly different, and one is a VM configured to match the first three as closely as possible with virtual hardware. The script checks the current kernel version, (e.g. "GENERIC.MP#302") logs it, runs sysupgrade, and after the reboot it checks the kernel version again. If it is different it logs it as a "success" and if it is still the same it logs it as a failure. All 6 systems were configured using the same autoinstall configuration and the upgrade script is identical on each unit. However, two of the three identical units always fail. When I remote into either system and manually run the upgrade script it also fails. I was able to get onsite with one of them where I connected a monitor and keyboard and manually ran the script to observe the results but oddly enough it succeeded so I learned nothing actionable. However it continues to fail the weekly upgrade. I have confirmed that the script permissions are identical on the working and nonworking units. The 4 units that successfully upgrade leave a mail message with a log of the upgrade process. However I have been unable to find any record or log on the systems that are failing to help me figure out why this isn't working. The only difference I can identify between the systems is that "auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the two systems that fail, but are properly removed on the 4 that succeed. I would appreciate any suggestions of what else I can try or check to figure out what is causing this issue. Thanks Judah
Re: pkg_add logs
On Mon, Apr 02, 2018 at 12:08:55PM +0200, Damien Thiriet wrote: > Hello misc@, > > > I have been looking for the date I last updated qgis. Thanks to this > old thread, > https://marc.info/?l=openbsd-misc&m=119449610716702&w=2 > I could find what I was looking for date using stat(1). > > However man pkg_add states that > "pkg_add will syslog(3) installations and updates by default" > > I checked my syslog.conf but couldn't find the file where pkg_add logs > by default. > > So here is my newbie question : where would I find pkg_add logs ? > > Best regards, > > > Damien Thiriet > /var/log/messages -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
Re: rotate logs
* x03 [090308 16:16]: > hello folks! > > Have way to add an entry to syslogd just for rotation? > I mean use syslogd to rotate all kinds of logs in /var/log/* > > Thanks a lot > man 8 newsyslog HTH, Jim
Re: rotate logs
Thanks ;) Jim Razmus wrote: * x03 [090308 16:16]: hello folks! Have way to add an entry to syslogd just for rotation? I mean use syslogd to rotate all kinds of logs in /var/log/* Thanks a lot man 8 newsyslog HTH, Jim
Re: rotate logs
syslogd does not rotate the logs. check newsyslog(8) cheers x03 wrote: hello folks! Have way to add an entry to syslogd just for rotation? I mean use syslogd to rotate all kinds of logs in /var/log/* Thanks a lot
Re: rotate logs
On 2009-03-08, x03 wrote: > hello folks! > > Have way to add an entry to syslogd just for rotation? > I mean use syslogd to rotate all kinds of logs in /var/log/* this reminds me of something I wanted to post for people using sensorsd who might find it useful: this writes sensorsd logs to a separate file, and mails you when a change is logged. saves a bit of messing around with scripts in sensorsd.conf for the usual case when you want to know if limits are exceeded. syslog.conf: !sensorsd *.* /var/log/sensors newsyslog.conf: /var/log/sensors644 7 *168 ZMB root ...and uncomment the "send log file notifications" in root's crontab.
Apache logs wierdness
I've just noticed something odd happening in my access_log. I have a mod_perl script which I use regularly. When I access this script, my access doesn't show up! Script errors however, do show up. When I access an html page, I show up. What's going on here? Chris Bennett
Re: rotating apache logs
On Friday 31 March 2006 09.05, you wrote: > Hi. What is the best way to rotate apache logs on OpenBSD? Ideally I > would like to create a new one at the beginning of each month. I > searched my system for logrotate and could not find it. > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com /etc/newsyslog.conf Like.... /var/www/logs/access_log644 60*$D0 Z /var/www/logs/httpd.pid SIGUSR1 One log per month sounds like they could grow a bit... I rotate every midnight. /Per-Olov -- GPG keyID: 4DB283CE GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE
Re: rotating apache logs
Selon Peter <[EMAIL PROTECTED]>: > Hi. What is the best way to rotate apache logs on OpenBSD? Ideally I > would like to create a new one at the beginning of each month. I > searched my system for logrotate and could not find it. > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com You can use newyslog for that. ie. in your /etc/newsyslog.conf /var/www/logs/access_log 644 31*$M1D0 Z "(apachectl stop; (while `pgrep httpd > /dev/null 2>&1`; do sleep 1; done); apachectl start) >/dev/null" /var/www/logs/error_log 644 31*$M1D0 Z "(apachectl stop; (while `pgrep httpd > /dev/null 2>&1`; do sleep 1; done); apachectl start) >/dev/null" -- Antoine
Re: rotating apache logs
On 2006-03-31 09:57:59 +0200, Antoine Jacoutot wrote: > You can use newyslog for that. And why does httpd(8) point to rotatelogs(8) instead? Best Martin -- http://www.tm.oneiros.de
Re: rotating apache logs
Hello Peter
below a small piece of code i found somewhere.
It works but mayby you wanna fix something.
Add in httpd.conf
LogFormat "%h %v %u %t \"%r\" %>s %b \"%{Referer}i\" " combined
.
CustomLog "| PATH_TO_ROTATELOGSDAY YOUR_LOGFILE" combined
/*
* Simple program to rotate Apache logs without having to kill the server.
*
* Contributed by Ben Laurie <[EMAIL PROTECTED]>
*
* 12 Mar 1996
*/
#define BUFSIZE 65536
#define MAX_PATH1024
#include
#include
#include
#include
#include
int main (int argc, char **argv)
{
char buf[BUFSIZE], buf2[MAX_PATH];
int nLogFD = -1;
int nRead;
int LogDay=-1;
char *szLogRoot;
time_t curtime;
struct tm *curtm;
char curtimestr[20];
if (argc != 2) {
fprintf(stderr,
"%s \n\n",
argv[0]);
#ifdef OS2
fprintf(stderr,
"Add this:\n\nTransferLog \"|%s.exe /some/where \"\n\n",
argv[0]);
#else
fprintf(stderr,
"Add this:\n\nTransferLog \"|%s /some/where \"\n\n",
argv[0]);
#endif
fprintf(stderr,
"to httpd.conf. \n\nThe generated name will be
/some/where.mm \n"
"where mmm is the year and month. \n"
"At the end of each month a new log is started.\n");
exit(1);
}
szLogRoot = argv[1];
for (;;)
{
nRead = read(0, buf, sizeof buf);
if (nRead == 0)
exit(3);
if (nRead < 0)
if (errno != EINTR)
exit(4);
curtime=time(NULL);
curtm=localtime(&curtime);
if (nLogFD >= 0 && (curtm->tm_mday != LogDay || nRead < 0)) {
close(nLogFD);
nLogFD = -1;
}
if (nLogFD < 0) {
LogDay=curtm->tm_mday;
sprintf(curtimestr, "%04d%02d%02d", 1900 + curtm->tm_year,
curtm->tm_mon+1, curtm->tm_mday);
sprintf(buf2, "%s.%s", szLogRoot, curtimestr);
nLogFD = open(buf2, O_WRONLY | O_CREAT | O_APPEND, 0666);
if (nLogFD < 0) {
perror(buf2);
exit(2);
}
}
if (write(nLogFD, buf, nRead) != nRead) {
perror(buf2);
exit(5);
}
}
}
--
GMX Produkte empfehlen und ganz einfach Geld verdienen!
Satte Provisionen f|r GMX Partner: http://www.gmx.net/de/go/partner
Re: rotating apache logs
On Fri, Mar 31, 2006 at 03:05:25AM -0500, Peter wrote: > Hi. What is the best way to rotate apache logs on OpenBSD? Ideally I > would like to create a new one at the beginning of each month. I > searched my system for logrotate and could not find it. After discussing that on the list [1], I endend up using cronolog (in the ports) and am quite satisfied with this. It has this "mothly" feature you want, too. [1] http://marc.theaimsgroup.com/?l=openbsd-misc&m=113410754403756&w=2 -- Olivier Mehani <[EMAIL PROTECTED]> PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1
Re: rotating apache logs
On Friday 31 March 2006 01:05, Peter wrote: > Hi. What is the best way to rotate apache logs on OpenBSD? Ideally I > would like to create a new one at the beginning of each month. I > searched my system for logrotate and could not find it. > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com Have a look at cronolog in the ports tree, I've used that with success. Frank
Re: rotating apache logs
On 31/03/06, Hiro Protagonist <[EMAIL PROTECTED]> wrote: > below a small piece of code i found somewhere. > It works but mayby you wanna fix something. [piece of code was here] Why bother with manually compiling some third-party utility, when rotatelogs(8) is already included with apache, see http://www.openbsd.org/cgi-bin/man.cgi?query=rotatelogs&sektion=8>. But most people still use newsyslog(8), AFAIAA.
Re: Managing PF logs
pf logs are stored in Tcpdump format, so you can parse them with tcpdump before dumping them into your analysis dbs On Fri, 7 Aug 2020 at 11:36, Carlos Lopez wrote: > Hi all, > > I am thinking about how could be the best option to inject PF logs in > Elasticsearch (or any similar platform). If I am not wrong, some years ago > there is an option using a shell wrapper to store all pf logs in ASCII > format and redirect all of them to a central syslog server (published in PF > FAQ). More or less it is what I am looking for. > > But maybe exists another best option in nowadays. Any ideas? Tips? > > Regards, > C. L. Martinez > > -- Kindest regards, Tom Smyth.
Re: Managing PF logs
On Fri, Aug 07, 2020 at 10:29:32AM +, Carlos Lopez wrote: > Hi all, > > I am thinking about how could be the best option to inject PF logs in > Elasticsearch (or any similar platform). If I am not wrong, some years ago > there is an option using a shell wrapper to store all pf logs in ASCII format > and redirect all of them to a central syslog server (published in PF FAQ). > More or less it is what I am looking for. > > But maybe exists another best option in nowadays. Any ideas? Tips? As Tom said, it is possible to use tcpdump to convert to text, then forward to syslog. The example from the old PF tutorial https://home.nuug.no/~peter/pf/newest/log2syslog.html should still work. All the best, -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Managing PF logs
Hello,
I use logstash with an input like this :
input {
pipe {
type => "pflog"
command => "doas /usr/sbin/tcpdump -l -v -n -n -e -s 160 -tt -i pflog0"
}
}
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : owner-m...@openbsd.org De la part de Peter N. M.
Hansteen
Envoyé : vendredi 7 août 2020 13:10
À : misc@openbsd.org
Objet : Re: Managing PF logs
On Fri, Aug 07, 2020 at 10:29:32AM +, Carlos Lopez wrote:
> Hi all,
>
> I am thinking about how could be the best option to inject PF logs in
> Elasticsearch (or any similar platform). If I am not wrong, some years ago
> there is an option using a shell wrapper to store all pf logs in ASCII format
> and redirect all of them to a central syslog server (published in PF FAQ).
> More or less it is what I am looking for.
>
> But maybe exists another best option in nowadays. Any ideas? Tips?
As Tom said, it is possible to use tcpdump to convert to text, then forward to
syslog.
The example from the old PF tutorial
https://home.nuug.no/~peter/pf/newest/log2syslog.html
should still work.
All the best,
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember
to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
_
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Re: Managing PF logs
Yep ... Pretty interesting Pierre ... but maybe is not a good idea to install
JDK in a fw gateway ... In any case, good catch.
But maybe the best option is to do it using syslog ... I will think about it
this weekend ... Many thanks to all for your help.
On 07/08/2020, 16:35, "owner-m...@openbsd.org on behalf of
pierre1.bar...@orange.com" wrote:
Hello,
I use logstash with an input like this :
input {
pipe {
type => "pflog"
command => "doas /usr/sbin/tcpdump -l -v -n -n -e -s 160 -tt -i pflog0"
}
}
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : owner-m...@openbsd.org De la part de Peter N.
M. Hansteen
Envoyé : vendredi 7 août 2020 13:10
À : misc@openbsd.org
Objet : Re: Managing PF logs
On Fri, Aug 07, 2020 at 10:29:32AM +, Carlos Lopez wrote:
> Hi all,
>
> I am thinking about how could be the best option to inject PF logs in
Elasticsearch (or any similar platform). If I am not wrong, some years ago
there is an option using a shell wrapper to store all pf logs in ASCII format
and redirect all of them to a central syslog server (published in PF FAQ). More
or less it is what I am looking for.
>
> But maybe exists another best option in nowadays. Any ideas? Tips?
As Tom said, it is possible to use tcpdump to convert to text, then forward
to syslog.
The example from the old PF tutorial
https://home.nuug.no/~peter/pf/newest/log2syslog.html
should still work.
All the best,
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember
to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
_
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Re: sysupgrade failure logs
On Sun, Feb 14, 2021 at 12:02:07PM -0500, Judah Kocher wrote: > Hello folks, > > I am having an issue with sysupgrade and I have had trouble finding the > source of the problem so I hope someone here might be able and willing to > point me in the right direction. > > I have 6 small systems running OpenBSD -current and I have a basic script > which upgrades to the latest snapshot weekly. The systems are all relatively > similar. Three are the exact same piece of hardware, two are slightly > different, and one is a VM configured to match the first three as closely as > possible with virtual hardware. > > The script checks the current kernel version, (e.g. "GENERIC.MP#302") logs > it, runs sysupgrade, and after the reboot it checks the kernel version > again. If it is different it logs it as a "success" and if it is still the > same it logs it as a failure. > > All 6 systems were configured using the same autoinstall configuration and > the upgrade script is identical on each unit. However, two of the three > identical units always fail. When I remote into either system and manually > run the upgrade script it also fails. I was able to get onsite with one of > them where I connected a monitor and keyboard and manually ran the script to > observe the results but oddly enough it succeeded so I learned nothing > actionable. However it continues to fail the weekly upgrade. I have > confirmed that the script permissions are identical on the working and > nonworking units. > > The 4 units that successfully upgrade leave a mail message with a log of the > upgrade process. However I have been unable to find any record or log on the > systems that are failing to help me figure out why this isn't working. The > only difference I can identify between the systems is that > "auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the two > systems that fail, but are properly removed on the 4 that succeed. > > I would appreciate any suggestions of what else I can try or check to figure > out what is causing this issue. > > Thanks > > Judah > Lesson 1: always get machines with remote console access. It wil save the day some day and help in diagnosing issues. On the system that succeeded when you were watching on the console, did automaic sysupgardes started to work after that? In general, my guess would be a boot.conf contents that prevent the automatic upgrade to work. Or maybe you have very old bootloaders on the failing mahcines. BTW, kernel # cannot be used to identify a kernel. -Otto
Re: sysupgrade failure logs
What are the permissions on the bsd.upgrade that's left behind? If they are still +x then your issue is with the boot loader, maybe that boot.conf otto suggested. If they are -x then the boot loader started the install kernel but something went wrong. On 14 February 2021 18:02:07 CET, Judah Kocher wrote: >Hello folks, > >I am having an issue with sysupgrade and I have had trouble finding the > >source of the problem so I hope someone here might be able and willing >to point me in the right direction. > >I have 6 small systems running OpenBSD -current and I have a basic >script which upgrades to the latest snapshot weekly. The systems are >all >relatively similar. Three are the exact same piece of hardware, two are > >slightly different, and one is a VM configured to match the first three > >as closely as possible with virtual hardware. > >The script checks the current kernel version, (e.g. "GENERIC.MP#302") >logs it, runs sysupgrade, and after the reboot it checks the kernel >version again. If it is different it logs it as a "success" and if it >is >still the same it logs it as a failure. > >All 6 systems were configured using the same autoinstall configuration >and the upgrade script is identical on each unit. However, two of the >three identical units always fail. When I remote into either system and > >manually run the upgrade script it also fails. I was able to get onsite > >with one of them where I connected a monitor and keyboard and manually >ran the script to observe the results but oddly enough it succeeded so >I >learned nothing actionable. However it continues to fail the weekly >upgrade. I have confirmed that the script permissions are identical on >the working and nonworking units. > >The 4 units that successfully upgrade leave a mail message with a log >of >the upgrade process. However I have been unable to find any record or >log on the systems that are failing to help me figure out why this >isn't >working. The only difference I can identify between the systems is that > >"auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the >two >systems that fail, but are properly removed on the 4 that succeed. > >I would appreciate any suggestions of what else I can try or check to >figure out what is causing this issue. > >Thanks > >Judah -- Sent from a mobile device. Please excuse poor formating.
Re: sysupgrade failure logs
On 2/14/21 7:02 PM, Judah Kocher wrote: Hello folks, I am having an issue with sysupgrade and I have had trouble finding the source of the problem so I hope someone here might be able and willing to point me in the right direction. I have 6 small systems running OpenBSD -current and I have a basic script which upgrades to the latest snapshot weekly. The systems are all relatively similar. Three are the exact same piece of hardware, two are slightly different, and one is a VM configured to match the first three as closely as possible with virtual hardware. The script checks the current kernel version, (e.g. "GENERIC.MP#302") logs it, runs sysupgrade, and after the reboot it checks the kernel version again. If it is different it logs it as a "success" and if it is still the same it logs it as a failure. All 6 systems were configured using the same autoinstall configuration and the upgrade script is identical on each unit. However, two of the three identical units always fail. When I remote into either system and manually run the upgrade script it also fails. I was able to get onsite with one of them where I connected a monitor and keyboard and manually ran the script to observe the results but oddly enough it succeeded so I learned nothing actionable. However it continues to fail the weekly upgrade. I have confirmed that the script permissions are identical on the working and nonworking units. The 4 units that successfully upgrade leave a mail message with a log of the upgrade process. However I have been unable to find any record or log on the systems that are failing to help me figure out why this isn't working. The only difference I can identify between the systems is that "auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the two systems that fail, but are properly removed on the 4 that succeed. I would appreciate any suggestions of what else I can try or check to figure out what is causing this issue. Thanks Judah Care to show a script ? otherwise it looks like rather lengthy mathematical problem with quite some variables.
Re: sysupgrade failure logs
Thanks to each of you for your replies, Lesson 1: always get machines
with remote console access. It wil save the day some day and help in
diagnosing issues. Having remote console access would be sweet, but
unfortunately that goes far beyond the hobbyist price point I currently
have to work with. On the system that succeeded when you were watching
on the console, did automaic sysupgardes started to work after that? It
did not. This unit still fails the weekly upgrade. In general, my guess
would be a boot.conf contents that prevent the automatic upgrade to
work. Or maybe you have very old bootloaders on the failing mahcines. I
do not have an /etc/boot.conf file on any of these systems. Both the
units having issues are less than 12 months old so I wouldn't think the
bootloader age would be an issue. I have both older and newer units that
are working correctly. Are there major recent changes you are aware of
that might lead to something like this? BTW, kernel # cannot be used to
identify a kernel. Interesting. When I realized two of my machines were
still on old snapshots it seemed like a a simple metric to use for
tracking this. The actual number isn't really as relevant to me at this
point as the fact that it does or does not change. Could the update be
partially and/or completely succeeding and the kernel # staying the
same? In my limited experience following -current for the last 4+ years
every snapshot comes with a different #. -Otto
Care to show a script ? otherwise it looks like rather lengthy
mathematical problem with quite some variables.
The script is very basic. I didn't show it originally because I know from reading
various threads in the past that many of the folks on this list find a
"non-default" install abhorrent and I wasn't interested in dragging that into
this. However, here are the complete script contents:
#!/bin/sh
# Fetch current system version
CURRENT=`uname -a | awk '{print $4}'`
# download latest snapshot but do not install
doas sysupgrade -n -s
# Delete unwanted sets
doas rm /home/_sysupgrade/x*
doas rm /home/_sysupgrade/g*
doas rm /home/_sysupgrade/c*
# Log System Time
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
second=`date +%S`
echo "System Snapshot upgrade started from $CURRENT at $hour:$minute:$second on
$month/$day/$year" >> /home/$USER/systemLog
doas reboot
I have a separate script that runs on each boot which checks if an
upgrade attempt was the last logged item and fetches the current system version
to compare. If it is the same it logs a failure. If it is different it logs the
new version #. Either way it emails me the results. This script is running on
all 6 systems.
.
What are the permissions on the bsd.upgrade that's left behind? If they
are still +x then your issue is with the boot loader, maybe that
boot.conf otto suggested. If they are -x then the boot loader started
the install kernel but something went wrong. The permissions of the
left-behind bsd.upgrade are -rw--- 1 root
On 14 February 2021 18:02:07 CET, Judah Kocher wrote:
Hello folks,
I am having an issue with sysupgrade and I have had trouble finding the
source of the problem so I hope someone here might be able and willing
to point me in the right direction.
I have 6 small systems running OpenBSD -current and I have a basic
script which upgrades to the latest snapshot weekly. The systems are
all
relatively similar. Three are the exact same piece of hardware, two are
slightly different, and one is a VM configured to match the first three
as closely as possible with virtual hardware.
The script checks the current kernel version, (e.g. "GENERIC.MP#302")
logs it, runs sysupgrade, and after the reboot it checks the kernel
version again. If it is different it logs it as a "success" and if it
is
still the same it logs it as a failure.
All 6 systems were configured using the same autoinstall configuration
and the upgrade script is identical on each unit. However, two of the
three identical units always fail. When I remote into either system and
manually run the upgrade script it also fails. I was able to get onsite
with one of them where I connected a monitor and keyboard and manually
ran the script to observe the results but oddly enough it succeeded so
I
learned nothing actionable. However it continues to fail the weekly
upgrade. I have confirmed that the script permissions are identical on
the working and nonworking units.
The 4 units that successfully upgrade leave a mail message with a log
of
the upgrade process. However I have been unable to find any record or
log on the systems that are failing to help me figure out why this
isn't
working. The only difference I can identify between the systems is that
"auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the
two
syste
Re: sysupgrade failure logs
You are using sysupgrade -n, and then modifying the payload?
Let's be serious about this:
I think everyone should stop helping you, you are on your own because
what you are showing now is completely different from your original
simple claim that "sysupgrade does not work".
Or you should pay someone for the trouble you are causing yourself.
I am not joking.
Judah Kocher wrote:
> Thanks to each of you for your replies, Lesson 1: always get machines
> with remote console access. It wil save the day some day and help in
> diagnosing issues. Having remote console access would be sweet, but
> unfortunately that goes far beyond the hobbyist price point I currently
> have to work with. On the system that succeeded when you were watching
> on the console, did automaic sysupgardes started to work after that? It
> did not. This unit still fails the weekly upgrade. In general, my guess
> would be a boot.conf contents that prevent the automatic upgrade to
> work. Or maybe you have very old bootloaders on the failing mahcines. I
> do not have an /etc/boot.conf file on any of these systems. Both the
> units having issues are less than 12 months old so I wouldn't think the
> bootloader age would be an issue. I have both older and newer units that
> are working correctly. Are there major recent changes you are aware of
> that might lead to something like this? BTW, kernel # cannot be used to
> identify a kernel. Interesting. When I realized two of my machines were
> still on old snapshots it seemed like a a simple metric to use for
> tracking this. The actual number isn't really as relevant to me at this
> point as the fact that it does or does not change. Could the update be
> partially and/or completely succeeding and the kernel # staying the
> same? In my limited experience following -current for the last 4+ years
> every snapshot comes with a different #. Â -Otto
> Care to show a script ? otherwise it looks like rather lengthy
> mathematical problem with quite some variables.
> The script is very basic. I didn't show it originally because I know
> from reading various threads in the past that many of the folks on this list
> find a "non-default" install abhorrent and I wasn't interested in dragging
> that into this. However, here are the complete script contents:
>
> #!/bin/sh
>
> # Fetch current system version
> CURRENT=`uname -a | awk '{print $4}'`
>
> # download latest snapshot but do not install
> doas sysupgrade -n -s
>
> # Delete unwanted sets
> doas rm /home/_sysupgrade/x*
> doas rm /home/_sysupgrade/g*
> doas rm /home/_sysupgrade/c*
>
> # Log System Time
> year=`date +%Y`
> month=`date +%m`
> day=`date +%d`
> hour=`date +%H`
> minute=`date +%M`
> second=`date +%S`
>
> echo "System Snapshot upgrade started from $CURRENT at $hour:$minute:$second
> on $month/$day/$year" >> /home/$USER/systemLog
> doas reboot
>
>
> I have a separate script that runs on each boot which checks if an
> upgrade attempt was the last logged item and fetches the current system
> version to compare. If it is the same it logs a failure. If it is different
> it logs the new version #. Either way it emails me the results. This script
> is running on all 6 systems.
> .
>
>
> What are the permissions on the bsd.upgrade that's left behind? If they
> are still +x then your issue is with the boot loader, maybe that
> boot.conf otto suggested. If they are -x then the boot loader started
> the install kernel but something went wrong. The permissions of the
> left-behind bsd.upgrade are -rw--- 1 root
>
> > On 14 February 2021 18:02:07 CET, Judah Kocher wrote:
> >> Hello folks,
> >>
> >> I am having an issue with sysupgrade and I have had trouble finding the
> >>
> >> source of the problem so I hope someone here might be able and willing
> >> to point me in the right direction.
> >>
> >> I have 6 small systems running OpenBSD -current and I have a basic
> >> script which upgrades to the latest snapshot weekly. The systems are
> >> all
> >> relatively similar. Three are the exact same piece of hardware, two are
> >>
> >> slightly different, and one is a VM configured to match the first three
> >>
> >> as closely as possible with virtual hardware.
> >>
> >> The script checks the current kernel version, (e.g. "GENERIC.MP#302")
> >> logs it, runs sysupgrade, and after the reboot it checks the kernel
> >> version again. If it is different it logs it as a "success" and if it
> >> is
> >> still the same i
Re: sysupgrade failure logs
I had this nicely formatted when I sent it, but it seems to have been
reformatted elsewhere in transit. Hopefully this helps but if not I will
leave it be.
On 2/14/21 6:27 PM, Judah Kocher wrote:
Thanks to each of you for your replies,
Lesson 1: always get machines with remote console access. It wil save
the day some day and help in diagnosing issues.
Having remote console access would be sweet, but unfortunately that goes
far beyond the hobbyist price point I currently have to work with.
On the system that succeeded when you were watching on the console,
did automaic sysupgardes started to work after that?
It did not. This unit still fails the weekly upgrade.
In general, my guess would be a boot.conf contents that prevent the
automatic upgrade to work. Or maybe you have very old bootloaders on
the failing mahcines.
I do not have an /etc/boot.conf file on any of these systems. Both the
units having issues are less than 12 months old so I wouldn't think the
bootloader age would be an issue. I have both older and newer units that
are working correctly. Are there major recent changes you are aware of
that might lead to something like this?
BTW, kernel # cannot be used to identify a kernel.
Interesting. When I realized two of my machines were still on old
snapshots it seemed like a a simple metric to use for tracking this. The
actual number isn't really as relevant to me at this point as the fact
that it does or does not change. Could the update be partially and/or
completely succeeding and the kernel # staying the same? In my limited
experience following -current for the last 4+ years every snapshot comes
with a different #.
-Otto
Care to show a script ? otherwise it looks like rather lengthy
mathematical problem with quite some variables.
The script is very basic. I didn't show it originally because I
know from reading various threads in the past that many of the folks on
this list find a "non-default" install abhorrent and I wasn't interested
in dragging that into this. However, here are the complete script contents:
#!/bin/sh
# Fetch current system version
CURRENT=`uname -a | awk '{print $4}'`
# download latest snapshot but do not install
doas sysupgrade -n -s
# Delete unwanted sets
doas rm /home/_sysupgrade/x*
doas rm /home/_sysupgrade/g*
doas rm /home/_sysupgrade/c*
# Log System Time
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
second=`date +%S`
echo "System Snapshot upgrade started from $CURRENT at
$hour:$minute:$second on $month/$day/$year" >> /home/$USER/systemLog
doas reboot
I have a separate script that runs on each boot which checks if an
upgrade attempt was the last logged item and fetches the current
system version to compare. If it is the same it logs a failure. If it
is different it logs the new version #. Either way it emails me the
results. This script is running on all 6 systems.
.
What are the permissions on the bsd.upgrade that's left behind? If
they are still +x then your issue is with the boot loader, maybe that
boot.conf otto suggested. If they are -x then the boot loader started
the install kernel but something went wrong.
The permissions of the left-behind bsd.upgrade are -rw--- 1 root
On 14 February 2021 18:02:07 CET, Judah Kocher
wrote:
Hello folks,
I am having an issue with sysupgrade and I have had trouble finding the
source of the problem so I hope someone here might be able and willing
to point me in the right direction.
I have 6 small systems running OpenBSD -current and I have a basic
script which upgrades to the latest snapshot weekly. The systems are
all
relatively similar. Three are the exact same piece of hardware, two are
slightly different, and one is a VM configured to match the first three
as closely as possible with virtual hardware.
The script checks the current kernel version, (e.g. "GENERIC.MP#302")
logs it, runs sysupgrade, and after the reboot it checks the kernel
version again. If it is different it logs it as a "success" and if it
is
still the same it logs it as a failure.
All 6 systems were configured using the same autoinstall configuration
and the upgrade script is identical on each unit. However, two of the
three identical units always fail. When I remote into either system and
manually run the upgrade script it also fails. I was able to get onsite
with one of them where I connected a monitor and keyboard and manually
ran the script to observe the results but oddly enough it succeeded so
I
learned nothing actionable. However it continues to fail the weekly
upgrade. I have confirmed that the script permissions are identical on
the working and nonworking units.
The 4 units that successfully upgrade leave a mail message with a log
of
the upgrade process. However I have been unable to find any record or
log on the systems that are failing to help me figure out
Re: sysupgrade failure logs
You are outside the box, by changing tons of stuff. People who operate inside the box won't be able to help you. And it is even less likely when you are dishonest in the original email. You claimed your sysupgrade use was completely normal, but it isn't. It is far from normal. When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. Or, every month or so change the internals so that it will delete some people's machines. Does sysupgrade recommend what you do? No. But you do it. Do you understand the concept of "you own all the pieces"?
Re: sysupgrade failure logs
> On Feb 14, 2021, at 3:48 PM, Theo de Raadt wrote: > > We want to delete sysupgrade. I would expect this would merely be a slight roadblock to people hell-bent on doing things that aren’t documented or supported, while making release upgrades harder for newbies lacking the urge to “customize”. (Tho of course it was the status quo ante just a couple releases ago.) There’s probably not a software solution to “it hurts when I do this”.
Re: sysupgrade failure logs
On Sun, Feb 14, 2021 at 06:39:15PM -0500, Judah Kocher wrote: > I had this nicely formatted when I sent it, but it seems to have been > reformatted elsewhere in transit. Hopefully this helps but if not I will > leave it be. > > On 2/14/21 6:27 PM, Judah Kocher wrote: > > Thanks to each of you for your replies, > > > Lesson 1: always get machines with remote console access. It wil save > > the day some day and help in diagnosing issues. > Having remote console access would be sweet, but unfortunately that goes far > beyond the hobbyist price point I currently have to work with. No idea what your paying, but there are companies that do provide (serial) console on all there offerings, like arp networks or openbsd.amsterdam. -Otto
Re: sysupgrade failure logs
Hello Theo, I never for a moment intended to convey that anyone "owed" me support of any kind for my outside-the-box use of this tool. While I don't understand your vitriolic response to someone else's application of your software for their own personal use in a way you do not condone, you are certainly entitled to be as outraged as you please. I remain grateful for the work you and others put into the OpenBSD operating system. It has been made clear on multiple occasions that use of sysupgrade with anything other than default responses is heretical and cancel-culture worthy but I don't mind breaking things while experimenting and do not blame anyone else when this happens, nor do I particularly care if anyone else is bothered by it as long as no actual harm is being done. If anyone cares to read my original query from an intellectually honest perspective I think they would be hard pressed to respond as you have. I never claimed my "sysupgrade use was completely normal" nor did I blame the sysupgrade tool for the issue I am attempting to diagnose. I did not mention my usage of it because logically it does not seem to be relevant and I was concerned it would become an excuse for people to fly off the handle. I only had and still only have one question. Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? If the answer is no, that's easy enough to say. If the answer is yes, that's also easy enough if anyone is willing to share where those logs would be found. If the answer is, "Maybe, but no one owes you that information" that is also perfectly true while kind of pointless to even bother saying, although a world where people only offer help to others when there is a financial obligation would be a dismal place indeed. I did not and do not expect anyone else to solve my problem for me. If you have reason to believe that my "mis-"usage of sysupgrade has anything at all to do with this issue, I'd be curious to know how you would explain it working on 4 out of 6 systems. Since it seems unlikely that the exact same tool would work two different ways on two identical systems then logically I would assume that some subtle difference exists between them and was hopeful that any records of the sysupgrade process would help me identify that difference. I have been using this script on these and other less similar systems ever since the sysupgrade tool was released with no issues, and therefore I think it's reasonable to to conclude that using it this way, while not officially sanctioned, has nothing to do with what's going on in this particular case. Thank you again for your work on OpenBSD, including sysupgrade. To everyone else on the mailing list, I do not apologize for asking a question but I do apologize for the drama it provoked. Judah On 2/14/21 6:44 PM, Theo de Raadt wrote: You are outside the box, by changing tons of stuff. People who operate inside the box won't be able to help you. And it is even less likely when you are dishonest in the original email. You claimed your sysupgrade use was completely normal, but it isn't. It is far from normal. When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. Or, every month or so change the internals so that it will delete some people's machines. Does sysupgrade recommend what you do? No. But you do it. Do you understand the concept of "you own all the pieces"?
Re: sysupgrade failure logs
Judah > I did not and do not expect anyone else to solve my problem for me. Your dishonesty is consistant. We supply it all as software. You can study it and find your problem. Blaming me solves nothing.
Re: sysupgrade failure logs
On Sun, 14 Feb 2021 16:44:37 -0700 "Theo de Raadt" wrote: > You are outside the box, by changing tons of stuff. > > People who operate inside the box won't be able to help you. > > And it is even less likely when you are dishonest in the original > email. You claimed your sysupgrade use was completely normal, but it > isn't. > > It is far from normal. > > When we get reports like this where people "touch the > insides", both Florian and I regret that sysupgrade ever > arrived in the system. > > We want to delete sysupgrade. Or, every month or so change the > internals so that it will delete some people's machines. > > Does sysupgrade recommend what you do? No. But you do it. Do you > understand the concept of "you own all the pieces"? > I am confident that I can speak for for ... a non-zero number of people who use sysupgrade the way it says to on the box and would miss it if it went away. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: sysupgrade failure logs
On Mon, Feb 15, 2021 at 12:21:11PM -0500, Judah Kocher wrote: > Hello Theo, > > I never for a moment intended to convey that anyone "owed" me support of any > kind for my outside-the-box use of this tool. You couldn't be bothered to even send a dmesg or a copy of the script with the first email. OK, say you forgot. I do sometimes. Where was your immediate reply with those missing and always required items? >While I don't understand your > vitriolic response to someone else's application of your software for their > own personal use in a way you do not condone, you are certainly entitled to > be as outraged as you please. Read the tech@ archives. Such a simple script is constantly being criticized, give it new features, etc... This script was a gift. I ran systems for years without it. Don't like the default script? Open it up and modify to meet your special needs. Don't know how to write the code? Learn it. If you don't understand what this script does, you REALLY need to learn more about installs and upgrades. > I remain grateful for the work you and others > put into the OpenBSD operating system. It has been made clear on multiple > occasions that use of sysupgrade with anything other than default responses > is heretical and cancel-culture worthy You appreciate the work, but you already know the default responses? Then you are being rude. > but I don't mind breaking things > while experimenting and do not blame anyone else when this happens, nor do I > particularly care if anyone else is bothered by it as long as no actual harm > is being done. This is part of learning and a good attitude. > > If anyone cares to read my original query from an intellectually honest > perspective I think they would be hard pressed to respond as you have. I > never claimed my "sysupgrade use was completely normal" nor did I blame the > sysupgrade tool for the issue I am attempting to diagnose. I did not mention > my usage of it because logically it does not seem to be relevant and I was > concerned it would become an excuse for people to fly off the handle. I only > had and still only have one question. > > Does sysupgrade leave any kind of logging behind which could help me to > pinpoint why it is failing on one system while working on another apparently > identical system? Read the script before posting the questions about logging. > > If the answer is no, that's easy enough to say. If the answer is yes, that's > also easy enough if anyone is willing to share where those logs would be > found. If the answer is, "Maybe, but no one owes you that information" that > is also perfectly true while kind of pointless to even bother saying, > although a world where people only offer help to others when there is a > financial obligation would be a dismal place indeed. > Much of the world is indeed a dismal place. It's part of human nature. > I did not and do not expect anyone else to solve my problem for me. If you > have reason to believe that my "mis-"usage of sysupgrade has anything at all > to do with this issue, I'd be curious to know how you would explain it > working on 4 out of 6 systems. Since it seems unlikely that the exact same > tool would work two different ways on two identical systems then logically I > would assume that some subtle difference exists between them and was hopeful > that any records of the sysupgrade process would help me identify that > difference. I have been using this script on these and other less similar > systems ever since the sysupgrade tool was released with no issues, and > therefore I think it's reasonable to to conclude that using it this way, > while not officially sanctioned, has nothing to do with what's going on in > this particular case. I really find your method puzzling. I ran into financial troubles and had to drop a server running -current. So I added a second hard drive to boot onto in case a new snapshot broke the system on the server running -current. I also do not understand while you are running -current and automating installation on 6 systems. Does your script verify functionality on the first system before moving on to the others? Are you caching both the snapshot and package files on the first server? Then using those files only to update the other 5 systems. If not, then you are pretty much guaranteeing at some point that you will have 6 different systems running different snapshots and packages. That seems like a bad idea. If all 6 systems go down, how will you fix that mess? Please, please, please, format your messages to be readable! Use some newlines. Please leave the politically correct responses for elsewhere. Read the different lists. Everyone gets told on or off list when they do something
Re: sysupgrade failure logs
Hello, Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? You should get emails: Subject: hostname upgrade response file Subject: hostname upgrade log Subject: hostname rc.sysmerge output Subject: hostname rc.firsttime output If you don't get them, my best guess would be that the system didn't boot the upgrade kernel. In that case check the /etc/boot.conf first. For example $ cat /etc/boot.conf boot prevents the upgrade kernel from being used. (Because of that I have a simple "mv /etc/boot.conf /etc/boot.conf-Temp-sysupgrade", "mv /etc/boot.conf-Temp-sysupgrade /etc/boot.conf" in my Ansible upgrade script.)
Re: sysupgrade failure logs
> On Sun, 14 Feb 2021 16:44:37 -0700 > "Theo de Raadt" wrote: > >> You are outside the box, by changing tons of stuff. >> >> People who operate inside the box won't be able to help you. >> >> And it is even less likely when you are dishonest in the original >> email. You claimed your sysupgrade use was completely normal, but it >> isn't. >> >> It is far from normal. >> >> When we get reports like this where people "touch the >> insides",both Florian and I regret that sysupgrade ever >> arrived in the system. >> >> We want to delete sysupgrade. Or, every month or so change the >> internals so that it will delete some people's machines. >> >> Does sysupgrade recommend what you do? No. But you do it. Do you >> understand the concept of "you own all the pieces"? >> > > I am confident that I can speak for for ... a non-zero number of > people who use sysupgrade the way it says to on the box and would miss > it if it went away. > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > Edward, Please increase your non-zero people number by one! I like sysupgrade Jay
Re: sysupgrade failure logs
On 2/15/21 7:21 PM, Judah Kocher wrote: Hello Theo, I never for a moment intended to convey that anyone "owed" me support of any kind for my outside-the-box use of this tool. While I don't understand your vitriolic response to someone else's application of your software for their own personal use in a way you do not condone, you are certainly entitled to be as outraged as you please. I remain grateful for the work you and others put into the OpenBSD operating system. It has been made clear on multiple occasions that use of sysupgrade with anything other than default responses is heretical and cancel-culture worthy but I don't mind breaking things while experimenting and do not blame anyone else when this happens, nor do I particularly care if anyone else is bothered by it as long as no actual harm is being done. If anyone cares to read my original query from an intellectually honest perspective I think they would be hard pressed to respond as you have. I never claimed my "sysupgrade use was completely normal" nor did I blame the sysupgrade tool for the issue I am attempting to diagnose. I did not mention my usage of it because logically it does not seem to be relevant and I was concerned it would become an excuse for people to fly off the handle. I only had and still only have one question. Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? If the answer is no, that's easy enough to say. If the answer is yes, that's also easy enough if anyone is willing to share where those logs would be found. If the answer is, "Maybe, but no one owes you that information" that is also perfectly true while kind of pointless to even bother saying, although a world where people only offer help to others when there is a financial obligation would be a dismal place indeed. I did not and do not expect anyone else to solve my problem for me. If you have reason to believe that my "mis-"usage of sysupgrade has anything at all to do with this issue, I'd be curious to know how you would explain it working on 4 out of 6 systems. Since it seems unlikely that the exact same tool would work two different ways on two identical systems then logically I would assume that some subtle difference exists between them and was hopeful that any records of the sysupgrade process would help me identify that difference. I have been using this script on these and other less similar systems ever since the sysupgrade tool was released with no issues, and therefore I think it's reasonable to to conclude that using it this way, while not officially sanctioned, has nothing to do with what's going on in this particular case. Thank you again for your work on OpenBSD, including sysupgrade. To everyone else on the mailing list, I do not apologize for asking a question but I do apologize for the drama it provoked. Judah On 2/14/21 6:44 PM, Theo de Raadt wrote: You are outside the box, by changing tons of stuff. People who operate inside the box won't be able to help you. And it is even less likely when you are dishonest in the original email. You claimed your sysupgrade use was completely normal, but it isn't. It is far from normal. When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. Or, every month or so change the internals so that it will delete some people's machines. Does sysupgrade recommend what you do? No. But you do it. Do you understand the concept of "you own all the pieces"? The drama was there, but not of Theo, but mine and someone else who kinda derailed this splitting this topic in separate threads "deleting sysupgrade" and "not deleting sysupgrade", however, It might be better to use stable for unattended systems, while just having 'syspatch && pkg_add -u' script in cron for systems that are not intended to be so much interactively used. If sysupgrade(8) does not mention any logging done by it it likely doesnt, and as 'whereis sysupgrade' shows it is at /usr/sbin/sysupgrade, and its a shell script which can be viewed by an unprivilleged user using something like less. And it is not that long to investigate or improve on your own. As for your use of it, you might be better with your own custom way of upgrading, that you can handle and log on your own. Just my 2 cents. Keep it Simple Stupid. P.S. Sorry, but I've never used mailing lists before (since few days ago) and I just sent this reply to bugs instead of here.
Re: sysupgrade failure logs
On 2/15/21 2:14 PM, Ed Ahlsen-Girard wrote: > I am confident that I can speak for for ... a non-zero number of > people who use sysupgrade the way it says to on the box and would miss > it if it went away. +1 Even though it is a little surprising that some people don't realise how easy it is to upgrade OpenBSD manually. I guess that surprise will just happen a little later on.
Re: sysupgrade failure logs
On Mon, February 15, 2021 11:14 am, Ed Ahlsen-Girard wrote: > I am confident that I can speak for for ... a non-zero number of > people who use sysupgrade the way it says to on the box and would miss > it if it went away. > +1 . Its simple to use, stable, convenient, luckly will bring more people to use the OS, and can normalize the various update scripts being used.
Re: sysupgrade failure logs
On Tue, February 16, 2021 1:16 pm, Mitch K. wrote: > > I've been unaware of sysupgrade until now. Looks like it was introduced > in 6.6. > > I've done several dot release upgrades manually. The process is > straightforward and > well-documented, like the rest of OpenBSD. It took me ~15-30 minutes per > system. Great learning opportunity too. > > Mitch K. I agree it is a great learn opportunity to upgrade releases by hand, will look into it. But also in the other hand, this is the kind of tool that can put this great OS into the mainstream use - cloud providers/VPS resellers adoption/offering for instance. Fabio Martins
Re: sysupgrade failure logs
Kevin Chadwick wrote on Tue [2021-Feb-16 12:52:42 +]: > On 2/15/21 2:14 PM, Ed Ahlsen-Girard wrote: > > I am confident that I can speak for for ... a non-zero number of > > people who use sysupgrade the way it says to on the box and would miss > > it if it went away. > > +1 > > Even though it is a little surprising that some people don't realise how easy > it > is to upgrade OpenBSD manually. I guess that surprise will just happen a > little > later on. > I've been unaware of sysupgrade until now. Looks like it was introduced in 6.6. I've done several dot release upgrades manually. The process is straightforward and well-documented, like the rest of OpenBSD. It took me ~15-30 minutes per system. Great learning opportunity too. Mitch K.
Clean OpenBSD's httpd logs
Hi all, Sorry if this question sounds stupid, but how can I avoid this type of entry in OpenBSD's httpd access.log: 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] [/favicon.ico] ?? Thanks. -- Greetings, C. L. Martinez
Strange relayd(8) logs meaning?
Hello, I have relayd(8) in front of nginx(8) to render a local Nextcloud instance. From time to time, the Nextcloud client fails saying "Host not found" which has no sense. The whole workstation still accesses the network and can resolve anything. relayd(8) listens on em1 IP and uses http protocol. nginx(8) listens on localhost. I have noted that relayd(8) writes such following entries in syslog when the Nextcloud client fails: May 18 16:45:54 server relayd[39533]: relay https_lan_relay, session 2816 (1 active), nextcloud, 192.168.0.48 -> :9081, done, PROPFIND -> 127.0.0.1:9081; PROPFIND; PROPFIND; PROPFIND; PROPFIND; PROPFIND; PROPFIND; REPORT; May 18 16:46:42 server relayd[97191]: relay https_lan_relay, session 3091 (1 active), nextcloud, 10.15.5.76 -> :9081, done, GET -> 127.0.0.1:9081; GET; PROPFIND; GET; GET; PROPFIND; GET; Are such logs (the HTTP commands pipelined with ;) indicating something weird happening on relayd or isn't it a clue for anything ; and I must dig somewhere else? Thank you, Joel C.
Re: Clean OpenBSD's httpd logs
* C. L. Martinez le [30-06-2016 12:50:36 +]:
> Hi all,
>
> Sorry if this question sounds stupid, but how can I avoid this type of
entry in OpenBSD's httpd access.log:
>
> 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/]
[/favicon.ico]
>
Hi,
in httpd.conf :
server "yourdomain.com" {
...
no log
}
You might want to keep access log. Separate errors in another file :
server "yourdomain.com" {
...
log access "yourdomain.access.log"
log error "yourdomain.errors.log"
}
see man httpd.conf for more :)
--
/Thuban/
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: Clean OpenBSD's httpd logs
On Thu, June 30, 2016 8:50 am, C. L. Martinez wrote: > Hi all, > > Sorry if this question sounds stupid, but how can I avoid this type of > entry in OpenBSD's httpd access.log: > > 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] > [/favicon.ico] > > ?? > Put a favicon.ico there? The web server has no idea if an attempt to get a missing file shouldn't be logged in some cases and not others. And all the major web browsers automatically look for /favicon.ico so it's going to happen. You might be able to redirect to an existing page but I think those might get logged anyway. Tim.
Re: Clean OpenBSD's httpd logs
Create a favicon.ico file, or ignore the error. httpd is just reporting that the user's browser is trying to fetch /favicon.ico and apparently it doesn't exist. Logging that as a 404 is standard behavior. You don't have one so httpd reports a 404. There are ways of telling the browser to not expect a favicon.ico or telling it that it exists somewhere else (that perhaps doesn't exist), but httpd in this case is really doing nothing wrong. The wisdom of favicons is a different story but they are standard. http://stackoverflow.com/questions/1321878/how-to-prevent-favicon-ico-requests One could argue that perhaps the web server shouldn't log favicon-related 404s...but then there will be someone trying to figure out why his/her favicons aren't showing up and will be looking at logs. On Thu, Jun 30, 2016 at 8:50 AM, C. L. Martinez wrote: > Hi all, > > Sorry if this question sounds stupid, but how can I avoid this type of > entry in OpenBSD's httpd access.log: > > 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] > [/favicon.ico] > > ?? > > Thanks. > -- > Greetings, > C. L. Martinez > > -- andrew fabbro and...@fabbro.org
Re: Clean OpenBSD's httpd logs
On Thu 30.Jun'16 at 15:21:05 +0200, Thuban wrote:
> * C. L. Martinez le [30-06-2016 12:50:36 +]:
> > Hi all,
> >
> > Sorry if this question sounds stupid, but how can I avoid this type of
> entry in OpenBSD's httpd access.log:
> >
> > 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/]
> [/favicon.ico]
> >
>
> Hi,
> in httpd.conf :
>
> server "yourdomain.com" {
> ...
> no log
> }
>
>
> You might want to keep access log. Separate errors in another file :
>
>
> server "yourdomain.com" {
> ...
> log access "yourdomain.access.log"
> log error "yourdomain.errors.log"
> }
>
>
> see man httpd.conf for more :)
>
>
> --
> /Thuban/
>
Thanks Thuban, but I want to log all requests to this web server :)
--
Greetings,
C. L. Martinez
Re: Clean OpenBSD's httpd logs
On 2016-06-30, C. L. Martinez wrote: > Hi all, > > Sorry if this question sounds stupid, but how can I avoid this type of entry > in OpenBSD's httpd access.log: > > 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] > [/favicon.ico] Untested, but in theory: set a location that matches the favicon.ico file and disable logging (e.g. "no log") in that location block.
Re: Clean OpenBSD's httpd logs
On Fri 1.Jul'16 at 7:39:13 +, Stuart Henderson wrote: > On 2016-06-30, C. L. Martinez wrote: > > Hi all, > > > > Sorry if this question sounds stupid, but how can I avoid this type of > > entry in OpenBSD's httpd access.log: > > > > 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] > > [/favicon.ico] > > Untested, but in theory: set a location that matches the favicon.ico file and > disable logging (e.g. "no log") in that location block. > Perfect!!! .. Works like a charm. Many thanks Stuart. -- Greetings, C. L. Martinez
Collect logs with syslog +hostname
Hi, I tried the new feature of syslogd to collect log messages from other syslog capable devices (in this case an OpenWRT router). I red syslog.conf many times, but I can't figure it why it doesn't work. [ns]~$ cat /etc/syslog.conf # $OpenBSD: syslog.conf,v 1.17 2005/05/25 07:35:38 david Exp $ # +wdr4900.bsdbg.net *.* /var/log/w4900 +* !!spamd daemon.err;daemon.warn;daemon.info /var/log/spamd !* !!ppp daemon.err;daemon.warn;daemon.info /var/log/ppp.log !* !!pptp daemon.err;daemon.warn;daemon.info /var/log/ppp.log !* *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages kern.debug;syslog,user.info /var/log/messages auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info/var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/log/uucp [ns]~$ ping wdr4900.bsdbg.net PING wdr4900.bsdbg.net (192.168.1.18): 56 data bytes 64 bytes from 192.168.1.18: icmp_seq=0 ttl=64 time=0.267 ms 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=0.220 ms 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=0.228 ms --- wdr4900.bsdbg.net ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.220/0.238/0.267/0.024 ms OpenBSD 5.8-beta (GENERIC.MP) #1152: Tue Jul 14 12:08:52 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4008378368 (3822MB) avail mem = 3883024384 (3703MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root
PF state limits and logs
Hello Recently I've had problems because my firewall (4.1-stable) has hit states limit. I was surprised when I found nothing in logs (debug urgent) . Is it intented or is it an oversight ? Regards Piotrek
ntpd error message filling logs
I have a GENERIC 4.1 box running ntpd as a server that is now part of au.pool.ntp.org and suddenly (once the world discovered it) the logs began to fill with entries like: Oct 19 16:46:05 freya ntpd[12012]: malformed packet received from 121.216.235.111 Oct 19 16:46:19 freya ntpd[12012]: malformed packet received from 144.131.135.143 Oct 19 16:46:25 freya ntpd[12012]: malformed packet received from 58.173.48.94 Oct 19 16:46:46 freya ntpd[12012]: malformed packet received from 58.168.107.247 Oct 19 16:47:20 freya ntpd[12012]: malformed packet received from 144.131.135.143 Oct 19 16:48:21 freya ntpd[12012]: malformed packet received from 144.131.135.143 Oct 19 16:48:29 freya ntpd[12012]: malformed packet received from 58.168.107.247 Oct 19 16:49:22 freya ntpd[12012]: malformed packet received from 144.131.135.143 So I went running to Mrs Google and she didn't say much really but one entry showed that somebody found that one version of Debian could deal with an early OBSD ntpd but a later Deb could not. I followed up some cvs entries for "our" ntpd and I can see the message text there but nothing much to let me figure out if it can be mitigated in any way. Ohh whoops! I just saw the tail -f daemon stop scrolling and it's now been silent for several minutes after nearly an hour where a bunch of Telstra (not my ISP) adsl customers repeatedly hammered the box. Anyway can someone please give me a clue as to what the effect is at t'other end clients? If it starts again what is the best tcpdump recipe to capture data that smart people need? I did a tcpdump -X -s 1500 -nettti rl0 udp and dst 218.214.194.118 but the output did not mean much to me . Any other clues? Thanx, Rod/ >From the land "down under": Australia. Do we look from up over?
X/xenodm logs: '_XSERVTransSocketUNIXAccept: accept() failed'
Hi All, I'm running 6.7 snapshot version (6.7 GENERIC.MP#273 amd64) as my main desktop with XFCE. A couple of time now I've noticed that these two files in /var/log have become unexpectedly huge: mjoelnir:log 23.06 09:44:15 # du -sh xenodm.log Xorg.0.log 378Mxenodm.log 487MXorg.0.log Apart from the usual startup/initialisation messages (below) Xorg.0.log contains many many instances of this message: > mjoelnir:log 23.06 09:51:59 # grep -c '_XSERVTransSocketUNIXAccept: accept() > failed' Xorg.0.log > 8800235 The same message is logged to xenodm.log i.e. > mjoelnir:log 23.06 09:53:14 # grep -c '_XSERVTransSocketUNIXAccept: accept() > failed' xenodm.log > 8800235 I don't know why or when this occurs, the xenodm messages aren't timestamped, but I assume that there must be some an issue with xenodm or the X11 subsystem. A search on the Internet only resulted in a couple of hits, from 2010 and 2012, at least one of which was related to the Cygwin platform - so quite different. I ran OpenBSD 6.6 for several months on this system (Intel NUC 8i5) and don't recall ever seeing this issue. The only other video issue/error I have noticed is this in the console or output of dmesg: > drm:pid54673:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic > update failure on pipe A I don't know if that is related. FYI: Excerpt from Xorg.0.log > [26.343] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem > (Operation not permitted) > Check that you have set 'machdep.allowaperture=1' > in /etc/sysctl.conf and reboot your machine > refer to xf86(4) for details > [26.343]linear framebuffer access unavailable > [26.373] (--) Using wscons driver on /dev/ttyC4 > [26.386] > X.Org X Server 1.20.8 > X Protocol Version 11, Revision 0 > [26.386] Build Operating System: OpenBSD 6.7 amd64 > [26.386] Current Operating System: OpenBSD mjoelnir.fritz.box 6.7 > GENERIC.MP#273 amd64 > [26.386] Build Date: 15 June 2020 07:46:53PM > [26.386] > [26.386] Current version of pixman: 0.38.4 > [26.386]Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [26.386] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [26.386] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 16 20:04:24 > 2020 > [26.388] (==) Using system config directory > "/usr/X11R6/share/X11/xorg.conf.d" > [26.389] (==) No Layout section. Using the first Screen section. > [26.389] (==) No screen section available. Using defaults. > [26.389] (**) |-->Screen "Default Screen Section" (0) > [26.389] (**) | |-->Monitor "" > [26.390] (==) No monitor specified for screen "Default Screen Section". > Using a default monitor configuration. > [26.390] (==) Automatically adding devices > [26.390] (==) Automatically enabling devices > [26.390] (==) Not automatically adding GPU devices > [26.390] (==) Max clients allowed: 256, resource mask: 0x1f > [26.394] (==) FontPath set to: > /usr/X11R6/lib/X11/fonts/misc/, > /usr/X11R6/lib/X11/fonts/TTF/, > /usr/X11R6/lib/X11/fonts/OTF/, > /usr/X11R6/lib/X11/fonts/Type1/, > /usr/X11R6/lib/X11/fonts/100dpi/, > /usr/X11R6/lib/X11/fonts/75dpi/ > [26.394] (==) ModulePath set to "/usr/X11R6/lib/modules" > [26.394] (II) The server relies on wscons to provide the list of input > devices. > If no devices become available, reconfigure wscons or disable > AutoAddDevices. > [26.394] (II) Loader magic: 0xeed1a3f9000 > [26.394] (II) Module ABI versions: > [26.394]X.Org ANSI C Emulation: 0.4 > [26.394]X.Org Video Driver: 24.1 > [26.394]X.Org XInput driver : 24.1 > [26.394]X.Org Server Extension : 10.0 > [26.395] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @ > 0xc000/16777216, 0x8000/1073741824, I/O @ 0x4000/64 > [26.395] (II) LoadModule: "glx" > [26.396] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so > [26.405] (II) Module glx: vendor="X.Org Foundation" > [26.405]compiled for 1.20.8, module version = 1.0.0 > [26.405]ABI class: X.Org Server Extension, version 10.0 > [26.405] (==) Matched modesetting as autoconfigured driver 0 > [26.405] (==) Assigned the driver to the xf86ConfigLayout > [26.405] (II) LoadModule: "modesetting" > [26.405] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so > [26.406] (II) Module modesetting: vendor="X.Org Foundation" > [26.406]compiled for 1.20.8, module version = 1.20.8 > [26.406]Module class: X.Org Video Driver > [26.406]ABI class: X.Org Video Driver, version 24.1 > [26.406] (II) modesetting: Driver for Modesetti
Deleting sysupgrade, was: sysupgrade failure logs
On 14/02/2021 23:44, Theo de Raadt wrote: When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. If this is not just a provocative statement, +1 from me. I've never liked unattended, automatic, Debian-style system upgrades. A lot of things can go wrong. -- Ottavio Caruso
http 408 messages in httpd logs
Starting from Feb 11 my httpd logs are filled with 408 messages: roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET / HTTP/1.1" 200 2535 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/styles.css HTTP/1.1" 200 282 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-novelas.png HTTP/1.1" 200 1812 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-comic.png HTTP/1.1" 200 2779 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/at.png HTTP/1.1" 200 324 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-devel.png HTTP/1.1" 200 4111 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-articles.png HTTP/1.1" 200 5835 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-about.jpg HTTP/1.1" 200 22211 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-social.png HTTP/1.1" 200 2782 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 This affects my main site only (I have other several virtual sites hosted in that machine), the only one using ssl on 443 port. As the example shows, some of them come right before a same source IP successful connection. In fact, the hidden ip above is me browsing my web site from another location. Besides, I didn't notice any delay, the pages are loaded as fast as before the messages started to appear. Increasing the request time out (in /etc/httpd.conf): connection request timeout 120 seems (not sure) to reduce a bit the number of messages. What intrigues me (and the reason I'm mentioning this here) is before Feb 11th, the date the first appeared, there is none, passed that date *all* requests generate that message. I follow -current and upgrade snapshots regularly. Could be some change in the system the cause?
[relayd] keep origin IP in logs
Hello, I use relayd to deal with HTTP headers as suggested here [1]. My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats not very handy to track bruteforce attacks (in example). Do you have any advice to keep the visitor IP in logs ? [1] : https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic -- :thuban:
Re: Collect logs with syslog +hostname
On 07/28/2015 02:41 PM, Atanas Vladimirov wrote: Hi, I tried the new feature of syslogd to collect log messages from other syslog capable devices (in this case an OpenWRT router). I red syslog.conf many times, but I can't figure it why it doesn't work. [ns]~$ cat /etc/syslog.conf # $OpenBSD: syslog.conf,v 1.17 2005/05/25 07:35:38 david Exp $ # +wdr4900.bsdbg.net *.* /var/log/w4900 move the above 2 lines to the end of your file. remove next line: +* next, add 192.168.1.18 wdr4900 to /etc/hosts and things will work
Re: Collect logs with syslog +hostname
On 07/28/2015 03:20 PM, Gregory Edigarov wrote: On 07/28/2015 02:41 PM, Atanas Vladimirov wrote: Hi, I tried the new feature of syslogd to collect log messages from other syslog capable devices (in this case an OpenWRT router). I red syslog.conf many times, but I can't figure it why it doesn't work. [ns]~$ cat /etc/syslog.conf # $OpenBSD: syslog.conf,v 1.17 2005/05/25 07:35:38 david Exp $ # +wdr4900.bsdbg.net *.* /var/log/w4900 move the above 2 lines to the end of your file. remove next line: +* next, add 192.168.1.18 wdr4900 to /etc/hosts also, change the syslog rule as: + wdr4900 *.* /var/log/w4900 and things will work
Re: Collect logs with syslog +hostname
On 28.07.2015 15:24, Gregory Edigarov wrote: On 07/28/2015 03:20 PM, Gregory Edigarov wrote: On 07/28/2015 02:41 PM, Atanas Vladimirov wrote: Hi, I tried the new feature of syslogd to collect log messages from other syslog capable devices (in this case an OpenWRT router). I red syslog.conf many times, but I can't figure it why it doesn't work. [ns]~$ cat /etc/syslog.conf # $OpenBSD: syslog.conf,v 1.17 2005/05/25 07:35:38 david Exp $ # +wdr4900.bsdbg.net *.* /var/log/w4900 move the above 2 lines to the end of your file. remove next line: +* next, add 192.168.1.18 wdr4900 to /etc/hosts also, change the syslog rule as: + wdr4900 *.* /var/log/w4900 and things will work Thanks for the hint. Actually I modified syslog.conf to begin with ++wdr4900 *.* /var/log/w4900 +* because I wanted all records from OpenWRT router to be in one place (/var/log/w4900). It seems that the real problem/misunderstanding was the part with /etc/hosts. Why syslogd doesn't use /etc/resolve.conf? This box is configured as recursive dns server (unbound).
Re: Collect logs with syslog +hostname
On Wed, 29 Jul 2015 15:46:46 +0300 Atanas Vladimirov wrote: > It seems that the real problem/misunderstanding was the part with > /etc/hosts. > Why syslogd doesn't use /etc/resolve.conf? > This box is configured as recursive dns server (unbound). > imho, /etc/hosts is much faster lookup than resolv.conf.
Re: Collect logs with syslog +hostname
On 29.07.2015 16:31, Gregory Edigarov wrote: On 07/29/2015 03:46 PM, Atanas Vladimirov wrote: Thanks for the hint. Actually I modified syslog.conf to begin with ++wdr4900 *.* /var/log/w4900 +* because I wanted all records from OpenWRT router to be in one place (/var/log/w4900). It seems that the real problem/misunderstanding was the part with /etc/hosts. Why syslogd doesn't use /etc/resolve.conf? Because at the time of developing the patch (I was developing it for myself) I wanted it to be as small and as less invasive as possible. I could have made it work with the resolver, but that was: 1. more invasive 2. less secure 3. it wouldn't be accepted I got it. Thanks for your work. If you need more complex log processing, you _should_ look at different projects like rsyslog, syslog-ng or nxlog. I don't need anything more complex. That's why I use OpenBSD. I think that it *may* be a good idea to add a note in SYSLOG.CONF(5) about /etc/hosts.
Re: ntpd error message filling logs
On Fri, 19 Oct 2007, RW wrote: > I have a GENERIC 4.1 box running ntpd as a server that is now part of > au.pool.ntp.org and suddenly (once the world discovered it) the logs > began to fill with entries like: > Oct 19 16:46:05 freya ntpd[12012]: malformed packet received from > 121.216.235.111 > Oct 19 16:46:19 freya ntpd[12012]: malformed packet received from > 144.131.135.143 > Oct 19 16:46:25 freya ntpd[12012]: malformed packet received from > 58.173.48.94 > Oct 19 16:46:46 freya ntpd[12012]: malformed packet received from > 58.168.107.247 > Oct 19 16:47:20 freya ntpd[12012]: malformed packet received from > 144.131.135.143 > Oct 19 16:48:21 freya ntpd[12012]: malformed packet received from > 144.131.135.143 > Oct 19 16:48:29 freya ntpd[12012]: malformed packet received from > 58.168.107.247 > Oct 19 16:49:22 freya ntpd[12012]: malformed packet received from > 144.131.135.143 > > So I went running to Mrs Google and she didn't say much really but one > entry showed that somebody found that one version of Debian could deal > with an early OBSD ntpd but a later Deb could not. > > I followed up some cvs entries for "our" ntpd and I can see the message > text there but nothing much to let me figure out if it can be mitigated > in any way. Well, you see ntpd doing the mitigation. It has recceived a request with an improper length. Some clients do that. It might even by some joker sending garbage to your ntpd. > > Ohh whoops! I just saw the tail -f daemon stop scrolling and it's now > been silent for several minutes after nearly an hour where a bunch of > Telstra (not my ISP) adsl customers repeatedly hammered the box. > > Anyway can someone please give me a clue as to what the effect is at > t'other end clients? ntpd will ignore these requests. The client will not receive a reply. Most clients conclude your server is down and start polling very infrequently to see if has come back. -Otto > > If it starts again what is the best tcpdump recipe to capture data that > smart people need? > I did a tcpdump -X -s 1500 -nettti rl0 udp and dst 218.214.194.118 but > the output did not mean much to me . > > Any other clues? > > Thanx, > Rod/ > > >From the land "down under": Australia. > Do we look from up over?
Syslogd problems with local4/OpenLDAP logs
Hi, I'm having problems getting log messages from syslogd for local4 messages. In syslog.conf, I added: local4.*/var/log/ldap.log I issued a restart for syslogd: kill -HUP `cat /var/run/syslog.pid` I compiled OpenLDAP: --with-syslog --with-debug I start OpenLDAP with: /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf I get no logs though. Anyone know what I'm missing here??? I have, as well, tried: logger -p local4.debug Hello World Still no joy =(
newsyslog errors in logs (OpenBSD 4.3)
I am getting this from the logs: newsyslog: warning - could not send SIGHUP to daemon Please give me a clue about how to fix this. I have Googled but what I found was not very helpful. thanks
seeing separate logs for differrent interfaces.
Hi,
I have 2 interfaces rl1 and sk0. I would like to see their logs separately using
#pfctl -s info
if I put
set loginterface rl1
set loginterface sk0
in /etc/pf.conf and type
#pfctl -s info
it only shows log for sk0
---
# cat /etc/pf.conf |grep loginterface
set loginterface rl1
set loginterface sk0
# pfctl -s info
Status: Enabled for 1 days 03:52:55 Debug: Urgent
Interface Stats for sk0 IPv4 IPv6
Bytes In638703430
Bytes Out 299895368 64
Packets In
Passed 4212990
Blocked 951980
Packets Out
Passed 4349921
Blocked 00
State Table Total Rate
current entries 87
searches 1822134 18.2/s
inserts656740.7/s
removals 655870.7/s
Counters
match 2403522.4/s
bad-offset 00.0/s
fragment 00.0/s
short 00.0/s
normalize 00.0/s
memory 00.0/s
bad-timestamp 00.0/s
congestion 00.0/s
ip-option 00.0/s
proto-cksum00.0/s
state-mismatch500.0/s
state-insert 00.0/s
state-limit00.0/s
src-limit 00.0/s
synproxy 00.0/s
#
If I make an interface group
log_ifs="{rl1, sk0}
set loginterface log_ifs
it shows the combined log
---
# pfctl -s info
Status: Enabled for 1 days 03:46:03 Debug: Urgent
Interface Stats for log_ifs IPv4 IPv6
Bytes In 00
Bytes Out 00
Packets In
Passed 00
Blocked 00
Packets Out
Passed 00
Blocked 00
State Table Total Rate
current entries 137
searches 1806931 18.1/s
inserts651460.7/s
removals 650090.7/s
Counters
match 2391432.4/s
bad-offset 00.0/s
fragment 00.0/s
short 00.0/s
normalize 00.0/s
memory 00.0/s
bad-timestamp 00.0/s
congestion 00.0/s
ip-option 00.0/s
proto-cksum00.0/s
state-mismatch460.0/s
state-insert 00.0/s
state-limit00.0/s
src-limit 00.0/s
synproxy 00.0/s
How do I do it correctly?
Thanks
--Siju
pf logs - no packet header data (4.8)
Hi! Setting up a firewall with 4.8, I was rather surprised to see that I don get any logged info from the blocked packets (beyond the fact that they were blocked). I assume I am missing some silly little thing... # tcpdump -n -e -ttt -i pflog0 tcpdump: listening on pflog0, link-type PFLOG Nov 14 18:24:28.487932 rule 5/(match) block in on xl0: [|ip] Nov 14 18:24:39.836219 rule 5/(match) block in on xl0: [|ip] Nov 14 18:24:41.776013 rule 5/(match) block in on xl0: [|ip] Nov 14 18:24:50.566842 rule 5/(match) block in on xl0: [|ip] Cheers, Julf
Apache logs filled with remote exploit trials
Hello, My apache logs are filled with these kind of attacks: [Sun Jan 15 20:53:19 2006] [error] [client 69.60.121.159] File does not exist: /htdocs/drupal/xmlrpc.php [Sun Jan 15 20:53:20 2006] [error] [client 69.60.121.159] File does not exist: /htdocs/phpgroupware/xmlrpc.php [Sun Jan 15 20:53:21 2006] [error] [client 69.60.121.159] File does not exist: /htdocs/wordpress/xmlrpc.php [Sun Jan 15 20:53:22 2006] [error] [client 69.60.121.159] File does not exist: /htdocs/xmlrpc.php [Sun Jan 15 20:53:23 2006] [error] [client 69.60.121.159] File does not exist: /htdocs/xmlrpc/xmlrpc.php [Sun Jan 15 20:53:24 2006] [error] [client 69.60.121.159] File does not exist: /htdocs/xmlsrv/xmlrpc.php How do "you" handle these kind of attacks? How or what do I have to use to dynamically block client Ips, that tries these type of attacks? Thank you very much Didier
Re: Deleting sysupgrade, was: sysupgrade failure logs
On 2021-02-15 09:33:03+, Ottavio Caruso wrote: > On 14/02/2021 23:44, Theo de Raadt wrote: > > When we get reports like this where people "touch the insides", both > > Florian and I regret that sysupgrade ever arrived in the system. > > We want to delete sysupgrade. > > If this is not just a provocative statement, +1 from me. > I've never liked unattended, automatic, Debian-style system upgrades. A lot > of things can go wrong. I think I stay in the box, and definitely appreciate sysupgrade (etc). It has made my openbsd use more secure and easier (given that I am not near your level of expertise here), so, thanks for it being there. Luke Call http://lukecall.net
Re: http 408 messages in httpd logs
On Tue, February 14, 2017 1:48 pm, Walter Alejandro Iglesias wrote: > Starting from Feb 11 my httpd logs are filled with 408 messages: > > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET / > HTTP/1.1" 200 2535 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/styles.css HTTP/1.1" 200 282 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/home-novelas.png HTTP/1.1" 200 1812 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/home-comic.png HTTP/1.1" 200 2779 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/at.png HTTP/1.1" 200 324 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/home-devel.png HTTP/1.1" 200 4111 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/home-articles.png HTTP/1.1" 200 5835 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/home-about.jpg HTTP/1.1" 200 22211 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET > /en/img/home-social.png HTTP/1.1" 200 2782 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " > 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " > 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " > 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " > 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " > 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " > 408 0 > > This affects my main site only (I have other several virtual sites > hosted in that machine), the only one using ssl on 443 port. As the > example shows, some of them come right before a same source IP > successful connection. In fact, the hidden ip above is me browsing my > web site from another location. Besides, I didn't notice any delay, the > pages are loaded as fast as before the messages started to appear. > > Increasing the request time out (in /etc/httpd.conf): > > connection request timeout 120 > > seems (not sure) to reduce a bit the number of messages. > > What intrigues me (and the reason I'm mentioning this here) is before > Feb 11th, the date the first appeared, there is none, passed that date > *all* requests generate that message. I follow -current and upgrade > snapshots regularly. Could be some change in the system the cause? > Yes: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server.c.diff?r1=1.106&r2=1.107&f=h I am assuming these are client pre-negotiated connections to speed up the user experience. I guess they were not properly being closed before. Unfortunately the commit message is not helpful here.
Re: http 408 messages in httpd logs
On Tue, February 14, 2017 2:27 pm, trondd wrote: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server.c.diff?r1=1.106&r2=1.107&f=h > > Unfortunately the commit message is not helpful here. > Ah hah. I knew it'd be somewhere: http://marc.info/?l=openbsd-cvs&m=148647072802851&w=2 I'd guess that the web browser was previously closing these connection long before the server was timing out.
Re: http 408 messages in httpd logs
> Am 14.02.2017 um 10:48 schrieb Walter Alejandro Iglesias : > > Starting from Feb 11 my httpd logs are filled with 408 messages: > > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET / HTTP/1.1" 200 2535 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/styles.css HTTP/1.1" 200 282 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-novelas.png HTTP/1.1" 200 1812 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-comic.png HTTP/1.1" 200 2779 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/at.png HTTP/1.1" 200 324 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-devel.png HTTP/1.1" 200 4111 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-articles.png HTTP/1.1" 200 5835 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-about.jpg HTTP/1.1" 200 22211 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET /en/img/home-social.png HTTP/1.1" 200 2782 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 > roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " 408 0 > > This affects my main site only (I have other several virtual sites > hosted in that machine), the only one using ssl on 443 port. As the > example shows, some of them come right before a same source IP > successful connection. In fact, the hidden ip above is me browsing my > web site from another location. Besides, I didn't notice any delay, the > pages are loaded as fast as before the messages started to appear. > > Increasing the request time out (in /etc/httpd.conf): > > connection request timeout 120 > > seems (not sure) to reduce a bit the number of messages. > > What intrigues me (and the reason I'm mentioning this here) is before > Feb 11th, the date the first appeared, there is none, passed that date > *all* requests generate that message. I follow -current and upgrade > snapshots regularly. Could be some change in the system the cause? > Yes, this is possible. Could you send me some more details including config? Reyk
Re: http 408 messages in httpd logs
> Am 14.02.2017 um 11:27 schrieb trondd : > >> On Tue, February 14, 2017 1:48 pm, Walter Alejandro Iglesias wrote: >> Starting from Feb 11 my httpd logs are filled with 408 messages: >> >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET / >> HTTP/1.1" 200 2535 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/styles.css HTTP/1.1" 200 282 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/home-novelas.png HTTP/1.1" 200 1812 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/home-comic.png HTTP/1.1" 200 2779 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/at.png HTTP/1.1" 200 324 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/home-devel.png HTTP/1.1" 200 4111 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/home-articles.png HTTP/1.1" 200 5835 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/home-about.jpg HTTP/1.1" 200 22211 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:48:32 +0100] "GET >> /en/img/home-social.png HTTP/1.1" 200 2782 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " >> 408 0 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " >> 408 0 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " >> 408 0 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " >> 408 0 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " >> 408 0 >> roquesor.com 79.xxx.150.xx4 - - [14/Feb/2017:15:49:32 +0100] " " >> 408 0 >> >> This affects my main site only (I have other several virtual sites >> hosted in that machine), the only one using ssl on 443 port. As the >> example shows, some of them come right before a same source IP >> successful connection. In fact, the hidden ip above is me browsing my >> web site from another location. Besides, I didn't notice any delay, the >> pages are loaded as fast as before the messages started to appear. >> >> Increasing the request time out (in /etc/httpd.conf): >> >> connection request timeout 120 >> >> seems (not sure) to reduce a bit the number of messages. >> >> What intrigues me (and the reason I'm mentioning this here) is before >> Feb 11th, the date the first appeared, there is none, passed that date >> *all* requests generate that message. I follow -current and upgrade >> snapshots regularly. Could be some change in the system the cause? >> > > Yes: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server.c.diff?r1= 1.106&r2=1.107&f=h > > I am assuming these are client pre-negotiated connections to speed up the > user experience. I guess they were not properly being closed before. > Unfortunately the commit message is not helpful here. > Good catch. Maybe changing it to a 408 was not the right thing here. Reyk
Re: http 408 messages in httpd logs
On Tue, Feb 14, 2017 at 02:34:24PM -0500, trondd wrote: > On Tue, February 14, 2017 2:27 pm, trondd wrote: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server.c.diff?r1=1.106&r2=1.107&f=h > > > > Unfortunately the commit message is not helpful here. > > > > Ah hah. I knew it'd be somewhere: > http://marc.info/?l=openbsd-cvs&m=148647072802851&w=2 > > I'd guess that the web browser was previously closing these connection > long before the server was timing out. > Trondd, big champ! :-)
Re: http 408 messages in httpd logs
On Tue, Feb 14, 2017 at 11:34:02AM -0800, Reyk Floeter wrote:
> Yes, this is possible. Could you send me some more
> details including config?
I just sent another message with the whole logs that didn't reach misc@,
too heavy :-). Here you go a simplified version:
OpenBSD 6.0-current (GENERIC.MP) #169: Mon Feb 13 17:44:12 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
# /etc/pf.conf
table {
0.0.0.0/8
10.0.0.0/8
127.0.0.1/8
169.254.0.0/16
172.16.0.0/12
192.0.2.0/24
192.88.99.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
}
table persist file "/etc/port22"
table persist file "/etc/port25"
set block-policy drop
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
antispoof log quick for egress
pass out quick all
pass in quick from { 192.168.1.1 192.168.1.102 192.168.1.103 } allow-opts
block quick inet proto udp from any to port \
{ bootps bootpc netbios-ns netbios-dgm }
block in log quick inet proto tcp from to port ssh
block in log quick inet proto tcp from to port smtp
block in log quick from { urpf-failed no-route }
pass in quick proto tcp to port { http https smtp smtps pop3s ssh }
pass in quick inet proto icmp all icmp-type 8 code 0
block in log all
# /etc/httpd.conf
ext_addr="em0"
r_timeout="300"
types {
include "/usr/share/misc/mime.types"
}
server "roquesor.com" {
listen on $ext_addr port 80
connection request timeout $r_timeout
alias "www.roquesor.com"
alias "es.roquesor.com"
block return 301 "https://$SERVER_NAME$REQUEST_URI";
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
log {
access "roquesor.com-access.log"
error "roquesor.com-error.log"
}
root "/htdocs/roquesor.com"
}
server "en.roquesor.com" {
listen on $ext_addr port 80
connection request timeout $r_timeout
block return 301 "https://$SERVER_NAME$REQUEST_URI";
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
log {
access "roquesor.com-access.log"
error "roquesor.com-error.log"
}
root "/htdocs/roquesor.com/en"
}
server "roquesor.com" {
listen on $ext_addr tls port 443
connection request timeout $r_timeout
alias "www.roquesor.com"
alias "es.roquesor.com"
tls certificate "/etc/ssl/server.crt"
tls key "/etc/ssl/private/server.key"
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
log {
access "roquesor.com-SSL-access.log"
error "roquesor.com-SSL-error.log"
}
root "/htdocs/roquesor.com"
}
server "en.roquesor.com" {
listen on $ext_addr tls port 443
connection request timeout $r_timeout
tls certificate "/etc/ssl/server.crt"
tls key "/etc/ssl/private/server.key"
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
log {
access "roquesor.com-SSL-access.log"
error "roquesor.com-SSL-error.log"
}
root "/htdocs/roquesor.com/en"
}
$ cat /var/www/logs/roquesor.com-access.log | sed -E 's/([^ ]
)([0-9]{1,3})\.(.*)/\1xxx.\3/'
Feb 12 00:00:01 server newsyslog[54883]: logfile turned over
roquesor.com xxx.249.75.40 - - [12/Feb/2017:00:03:02 +0100] " " 408 0
roquesor.com xxx.249.75.136 - - [12/Feb/2017:00:06:51 +0100] " " 408 0
roquesor.com xxx.249.75.58 - - [12/Feb/2017:00:10:18 +0100] " " 408 0
roquesor.com xxx.249.69.221 - - [12/Feb/2017:00:12:57 +0100] " " 408 0
roquesor.com xxx.249.75.47 - - [12/Feb/2017:00:13:01 +0100] " " 408 0
roquesor.com xxx.249.75.40 - - [12/Feb/2017:00:13:14 +0100] " " 408 0
roquesor.com xxx.249.69.233 - - [12/Feb/2017:00:15:23 +0100] " " 408 0
roquesor.com xxx.249.75.47 - - [12/Feb/2017:00:16:41 +0100] " " 408 0
www.roquesor.com xxx.180.228.163 - - [12/Feb/2017:00:18:04 +0100] "GET
/robots.txt HTTP/1.1" 200 36
www.roquesor.com xxx.180.228.163 - - [12/Feb/2017:00:18:05 +0100] "GET
/novelas.html HTTP/1.1" 200 1542
roquesor.com xxx.180.228.163 - - [12/Feb/2017:00:19:06
Re: [relayd] keep origin IP in logs
On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> Hello,
> I use relayd to deal with HTTP headers as suggested here [1].
> My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> not very handy to track bruteforce attacks (in example).
>
> Do you have any advice to keep the visitor IP in logs ?
>
> [1] :
> https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> --
> :thuban:
>
Hey,
It's commonly done by adding a X-Forwarded-For header with the origin IP.
>From the relayd.conf(5) man page:
http protocol "https" {
match header append "X-Forwarded-For" \
value "$REMOTE_ADDR"
match header append "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
... snip snip ...
}
I hope this helps you,
--
Kind regards,
Hiltjo
Re: [relayd] keep origin IP in logs
* Hiltjo Posthuma le [09-04-2017 11:42:23 +0200]:
> On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> > Hello,
> > I use relayd to deal with HTTP headers as suggested here [1].
> > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> > not very handy to track bruteforce attacks (in example).
> >
> > Do you have any advice to keep the visitor IP in logs ?
> >
> > [1] :
> > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> > --
> > :thuban:
> >
>
> Hey,
>
> It's commonly done by adding a X-Forwarded-For header with the origin IP.
>
> From the relayd.conf(5) man page:
>
>http protocol "https" {
>match header append "X-Forwarded-For" \
>value "$REMOTE_ADDR"
>match header append "X-Forwarded-By" \
>value "$SERVER_ADDR:$SERVER_PORT"
>
>... snip snip ...
>}
>
That's exactly what I use, but it doesn't seems to work :
# snip from httpd logs
test.yeuxdelibad.net 127.0.0.1 - - [09/Apr/2017:11:47:54 +0200] "GET /
HTTP/1.0" 200 0
Here is my full relayd.conf.
I tried to use "transparent" keyword but relay fail in this case.
# cat /etc/relayd.conf
table { 127.0.0.1 }
ext_ip = 192.168.1.2
http protocol "http" {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
match response header set "Cache-Control" value
"max-age=1814400"
match request header remove "Proxy"
match response header set "X-Xss-Protection" value "1;
mode=block"
match response header set "Frame-Options" value "SAMEORIGIN"
match response header set "X-Frame-Options" value "SAMEORIGIN"
match header append "X-Forwarded-For" \
value "$REMOTE_ADDR"
match header append "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
return error
}
relay "www" {
listen on $ext_ip port 80
protocol "http"
forward to port 8080 check tcp
}
Regards.
--
:thuban:
Re: [relayd] keep origin IP in logs
On Sun, Apr 09, 2017 at 11:51:25AM +0200, Thuban wrote:
> * Hiltjo Posthuma le [09-04-2017 11:42:23 +0200]:
> > On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> > > Hello,
> > > I use relayd to deal with HTTP headers as suggested here [1].
> > > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> > > not very handy to track bruteforce attacks (in example).
> > >
> > > Do you have any advice to keep the visitor IP in logs ?
> > >
> > > [1] :
> > > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> > > --
> > > :thuban:
> > >
> >
> > Hey,
> >
> > It's commonly done by adding a X-Forwarded-For header with the origin IP.
> >
> > From the relayd.conf(5) man page:
> >
> >http protocol "https" {
> >match header append "X-Forwarded-For" \
> >value "$REMOTE_ADDR"
> >match header append "X-Forwarded-By" \
> >value "$SERVER_ADDR:$SERVER_PORT"
> >
> >... snip snip ...
> >}
> >
>
> That's exactly what I use, but it doesn't seems to work :
>
> # snip from httpd logs
> test.yeuxdelibad.net 127.0.0.1 - - [09/Apr/2017:11:47:54 +0200] "GET /
> HTTP/1.0" 200 0
>
Hey,
In my example you should also log the "X-Forwarded-For" header in relayd or
your httpd. The source IP and headers were modified (non-transparant).
relayd can log headers (and other data) using for example:
match header log "User-Agent"
Additionally it can be useful to edit /etc/syslog.conf to log this to a
separate file like /var/log/relayd.
--
Kind regards,
Hiltjo
Re: [relayd] keep origin IP in logs
On 2017-04-09, Thuban wrote:
> * Hiltjo Posthuma le [09-04-2017 11:42:23 +0200]:
>> On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
>> > Hello,
>> > I use relayd to deal with HTTP headers as suggested here [1].
>> > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
>> > not very handy to track bruteforce attacks (in example).
>> >
>> > Do you have any advice to keep the visitor IP in logs ?
>> >
>> > [1] :
>> > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
>> > --
>> > :thuban:
>> >
>>
>> Hey,
>>
>> It's commonly done by adding a X-Forwarded-For header with the origin IP.
>>
>> From the relayd.conf(5) man page:
>>
>>http protocol "https" {
>>match header append "X-Forwarded-For" \
>>value "$REMOTE_ADDR"
>>match header append "X-Forwarded-By" \
>> value "$SERVER_ADDR:$SERVER_PORT"
"append" isn't good here, you don't want to trust whatever the client
sends in headers.
> That's exactly what I use, but it doesn't seems to work :
>
> # snip from httpd logs
> test.yeuxdelibad.net 127.0.0.1 - - [09/Apr/2017:11:47:54 +0200] "GET /
> HTTP/1.0" 200 0
You need to configure the webserver to log those headers. I don't
think httpd(8) allows it though.
> I tried to use "transparent" keyword but relay fail in this case.
This would be simpler as you then don't need to worry about changing
webserver logging or what the client sends in headers. I think it would
be better to debug this instead.
Re: [relayd] keep origin IP in logs
On Sun, Apr 09, 2017 at 11:30:37AM +, Stuart Henderson wrote:
> On 2017-04-09, Thuban wrote:
> > * Hiltjo Posthuma le [09-04-2017 11:42:23 +0200]:
> >> On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> >> > Hello,
> >> > I use relayd to deal with HTTP headers as suggested here [1].
> >> > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> >> > not very handy to track bruteforce attacks (in example).
> >> >
> >> > Do you have any advice to keep the visitor IP in logs ?
> >> >
> >> > [1] :
> >> > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> >> > --
> >> > :thuban:
> >> >
> >>
> >> It's commonly done by adding a X-Forwarded-For header with the origin IP.
> >>
> >> From the relayd.conf(5) man page:
> >>
> >>http protocol "https" {
> >>match header append "X-Forwarded-For" \
> >>value "$REMOTE_ADDR"
> >>match header append "X-Forwarded-By" \
> >>value "$SERVER_ADDR:$SERVER_PORT"
>
> "append" isn't good here, you don't want to trust whatever the client
> sends in headers.
>
Good point! I've send a relayd.conf(5) patch for this to tech@.
--
Kind regards,
Hiltjo
Re: [relayd] keep origin IP in logs
* Hiltjo Posthuma le [09-04-2017 14:06:48 +0200]:
> On Sun, Apr 09, 2017 at 11:30:37AM +, Stuart Henderson wrote:
> > On 2017-04-09, Thuban wrote:
> > > * Hiltjo Posthuma le [09-04-2017 11:42:23 +0200]:
> > >> On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> > >> > Hello,
> > >> > I use relayd to deal with HTTP headers as suggested here [1].
> > >> > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> > >> > not very handy to track bruteforce attacks (in example).
> > >> >
> > >> > Do you have any advice to keep the visitor IP in logs ?
> > >> >
> > >> > [1] :
> > >> > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> > >> > --
> > >> > :thuban:
> > >> >
> > >>
> > >> It's commonly done by adding a X-Forwarded-For header with the origin IP.
> > >>
> > >> From the relayd.conf(5) man page:
> > >>
> > >>http protocol "https" {
> > >>match header append "X-Forwarded-For" \
> > >>value "$REMOTE_ADDR"
> > >>match header append "X-Forwarded-By" \
> > >>value "$SERVER_ADDR:$SERVER_PORT"
> >
> > "append" isn't good here, you don't want to trust whatever the client
> > sends in headers.
> >
>
> Good point! I've send a relayd.conf(5) patch for this to tech@.
That's right indeed. The man page may have an alert on this.
So, transparent relay is what I need. Does anyone have a working
example ?
Just adding the "transparent" keyword doesn't work for me, the client
never access httpd.
Regards
--
:thuban:
kernel logs "v_type 1" and "f_type 1"
A firewall box (dual Atom N270, 2GB, 5 nics, running 5.8-current (GENERIC.MP) #1219) suddenly started logging v_type 1 f_type 1 (up to 40 times/sec) and stopped routing. The effect went away after disconnecting all but one nic. Any help appreciated, Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Re: Syslogd problems with local4/OpenLDAP logs
On Thursday 24 May 2007 10:58, neustream <[EMAIL PROTECTED]> wrote: > Hi, > > I'm having problems getting log messages from syslogd for local4 > messages. > > In syslog.conf, I added: > > local4.*/var/log/ldap.log > > I issued a restart for syslogd: > > kill -HUP `cat /var/run/syslog.pid` > > I compiled OpenLDAP: > > --with-syslog --with-debug > > I start OpenLDAP with: > > /usr/local/libexec/slapd -u _openldap -g _openldap -f > /etc/openldap/slapd.conf > > I get no logs though. Anyone know what I'm missing here??? Did you do a touch /var/log/ldap.log? > > I have, as well, tried: > > logger -p local4.debug Hello World > > Still no joy =( > > > !DSPAM:1,4655b7c782361076813867! -- Vijay Sankar ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]
Re: Syslogd problems with local4/OpenLDAP logs
Yes..I forgot to mention I did a: touch /var/log/ldap.log as root. I added, to newsyslog.conf /var/log/ldap.log root:wheel 640 7250 * Z as well. Vijay Sankar wrote: On Thursday 24 May 2007 10:58, neustream <[EMAIL PROTECTED]> wrote: Hi, I'm having problems getting log messages from syslogd for local4 messages. In syslog.conf, I added: local4.*/var/log/ldap.log I issued a restart for syslogd: kill -HUP `cat /var/run/syslog.pid` I compiled OpenLDAP: --with-syslog --with-debug I start OpenLDAP with: /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf I get no logs though. Anyone know what I'm missing here??? Did you do a touch /var/log/ldap.log? I have, as well, tried: logger -p local4.debug Hello World Still no joy =( !DSPAM:1,4655b7c782361076813867!
Re: Syslogd problems with local4/OpenLDAP logs
On Thursday 24 May 2007 11:23, neustream wrote: > Yes..I forgot to mention I did a: > > touch /var/log/ldap.log > > as root. > > I added, to newsyslog.conf > > /var/log/ldap.log root:wheel 640 7250 * Z > > as well. Not sure whether this is helpful. Does slapd start properly with the /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf ? Can you verify with a ps auwx | grep slapd that it is running and listening on port 389? On my test system, I got the following when I tried your startup command unable to open pid file "/var/run/slapd.pid" 13 (Permission denied) Probably something I am doing wrong but but when I start openldap as follows: /usr/local/libexec/slapd -h "ldap://127.0.01/ ldaps:///" slapd starts and logging works well. HTH, Vijay > > Vijay Sankar wrote: > > On Thursday 24 May 2007 10:58, neustream <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I'm having problems getting log messages from syslogd for local4 > >> messages. > >> > >> In syslog.conf, I added: > >> > >> local4.*/var/log/ldap.log > >> > >> I issued a restart for syslogd: > >> > >> kill -HUP `cat /var/run/syslog.pid` > >> > >> I compiled OpenLDAP: > >> > >> --with-syslog --with-debug > >> > >> I start OpenLDAP with: > >> > >> /usr/local/libexec/slapd -u _openldap -g _openldap -f > >> /etc/openldap/slapd.conf > >> > >> I get no logs though. Anyone know what I'm missing here??? > > > > Did you do a touch /var/log/ldap.log? > > > >> I have, as well, tried: > >> > >> logger -p local4.debug Hello World > >> > >> Still no joy =( > > !DSPAM:1,4655bd84207176107113666! -- Vijay Sankar ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]
Re: Syslogd problems with local4/OpenLDAP logs
On Thu, 24 May 2007, neustream wrote: Yes..I forgot to mention I did a: touch /var/log/ldap.log Yes but that the _openldap user have write access to the log file? -- Antoine
Re: Syslogd problems with local4/OpenLDAP logs
Thanks all for your help! Well yes slapd runs when I issue: /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf With "ps ax | grep slapd", I get: 3347 ?? Is 0:00.03 /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf With "netstat -na | grep LISTEN", I get: tcp0 0 *.389 *.*LISTEN I have populated OpenLDAP with entries which qmail and courier are able to read - works great. The only way I'm able to see logs is when I start up slapd with: /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf -d 255 Nice logs but it doesn't go to background. /***/ I have tried starting starting it, as you suggested: /usr/local/libexec/slapd -h "ldap://127.0.0.1/"; No logs yet. (Yes..i had to create the /var/run/openldap directory "chown -R _opendlap:_openldap /var/run/openldap" to get slapd to start the way I posted originally - permission issue in /var/run) // I have also tried "chown _openldap:_openldap /var/run/ldap.log" No logs yet. // Vijay Sankar wrote: On Thursday 24 May 2007 11:23, neustream wrote: Yes..I forgot to mention I did a: touch /var/log/ldap.log as root. I added, to newsyslog.conf /var/log/ldap.log root:wheel 640 7250 * Z as well. Not sure whether this is helpful. Does slapd start properly with the /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf ? Can you verify with a ps auwx | grep slapd that it is running and listening on port 389? On my test system, I got the following when I tried your startup command unable to open pid file "/var/run/slapd.pid" 13 (Permission denied) Probably something I am doing wrong but but when I start openldap as follows: /usr/local/libexec/slapd -h "ldap://127.0.01/ ldaps:///" slapd starts and logging works well. HTH, Vijay Vijay Sankar wrote: On Thursday 24 May 2007 10:58, neustream <[EMAIL PROTECTED]> wrote: Hi, I'm having problems getting log messages from syslogd for local4 messages. In syslog.conf, I added: local4.*/var/log/ldap.log I issued a restart for syslogd: kill -HUP `cat /var/run/syslog.pid` I compiled OpenLDAP: --with-syslog --with-debug I start OpenLDAP with: /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf I get no logs though. Anyone know what I'm missing here??? Did you do a touch /var/log/ldap.log? I have, as well, tried: logger -p local4.debug Hello World Still no joy =( !DSPAM:1,4655bd84207176107113666!
Re: Syslogd problems with local4/OpenLDAP logs
Ok..well I am thinking, if I have: local4.*/var/log/ldap.log in syslog.conf and I issue: kill -HUP `cat /var/run/syslog.pid` Then this command should work: logger -p local4.info Hello World and log to /var/run/ldap.log. When I issue: logger -p mail.info Hello World I get "Hello World" in my maillog. Anyone know why it wouldn't work for local4. This is OBSD 4.1. Thanks all for your time! Antoine Jacoutot wrote: On Thu, 24 May 2007, neustream wrote: Yes..I forgot to mention I did a: touch /var/log/ldap.log Yes but that the _openldap user have write access to the log file?
Re: Syslogd problems with local4/OpenLDAP logs
On 5/24/07, neustream <[EMAIL PROTECTED]> wrote: Hi, I'm having problems getting log messages from syslogd for local4 messages. In syslog.conf, I added: local4.*/var/log/ldap.log I issued a restart for syslogd: kill -HUP `cat /var/run/syslog.pid` I compiled OpenLDAP: --with-syslog --with-debug I start OpenLDAP with: /usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf I get no logs though. Anyone know what I'm missing here??? You've got tabs, or spaces between your local4.* and path? DS
Re: Syslogd problems with local4/OpenLDAP logs
On Thu, 24 May 2007, Darren Spruell wrote: You've got tabs, or spaces between your local4.* and path? DS Yea someone else with the the same comment as mine for the original poster see this thread related to syslog configuration for slapd http://www.openldap.org/lists/openldap-software/200111/msg00307.html appears to be a similar question asked in Nov 2001 diana
Re: Syslogd problems with local4/OpenLDAP logs
Thanks all for your help. I was using vim with tabs converted to spaces in my vimrc. I edited /etc/syslog.conf with vi and used tabs between local4.* and path. Works now! Diana Eichert wrote: On Thu, 24 May 2007, Darren Spruell wrote: You've got tabs, or spaces between your local4.* and path? DS Yea someone else with the the same comment as mine for the original poster see this thread related to syslog configuration for slapd http://www.openldap.org/lists/openldap-software/200111/msg00307.html appears to be a similar question asked in Nov 2001 diana
Re: Syslogd problems with local4/OpenLDAP logs
On Thu, 24 May 2007, neustream wrote: Thanks all for your help. I was using vim with tabs converted to spaces in my vimrc. I edited /etc/syslog.conf with vi and used tabs between local4.* and path. Works now! Great! I'd call that pretty good support, ~ 3.5 hours from your original post to resolution. g.day
Re: newsyslog errors in logs (OpenBSD 4.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Quoted from Pollywog on Sat, Jun 21, 2008 at 06:27:04PM +,: > I am getting this from the logs: > > newsyslog: warning - could not send SIGHUP to daemon > > Please give me a clue about how to fix this. I have Googled but > what I found was not very helpful. > > thanks > Okay, someone on the list more knowledgeable correct me if I'm wrong, but my first questions are: First, did you check to see if syslogd is running? ps -auxw |grep syslogd Second, does the user _syslogd exist in /etc/group? It needs to be there. Denny White - -- I have been a gigantic Rolling Stones fan since approximately the Spanish-American War. Dave Barry All messages scanned by ClamAssassin http://jameslick.com/clamassassin/ === GnuPG key : 0x1644E79A | http://wwwkeys.nl.pgp.net Fingerprint: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A === iD8DBQFIXVsvy0Ty5RZE55oRAiyNAJsFGDB3WAINVJBCQV9hSmIr7MizTgCgxDGY zUSqAjmKOFgNkektl8CouCg= =TIqc -END PGP SIGNATURE-
