I am working on a project to update syslog.conf files in our unix environment.
I discovered that many have duplicate entries. I don't know which will work or will they all work. Here are the existing entries.
auth.debug #10.X.XXXX.XX
auth.debug #arl-syslog.XXXXXX.net
I am to add the following
auth., authpriv. #arl-syslog.XXXXXX.net
What will happen with the existing entries if I add the last one? Will the first one still work? Will the second become redundant because of the one I add?
Thank you.
All entries are always evaluated, so both of your entries will be be effective.
The trouble is that your second entry is not really useful, since the priority field is not specified. I did not find any explicit mention of this case in the docs.
I have tested this with rsyslogd vers. 8.6 and when you do not specify the priority field it does not affect the logging for that facility.
E.g.:
authpriv.info /var/log/auth.log;SyslFormat
authpriv. /var/log/auth.log;SyslFormat
Messages for authpriv at level info and above will be logged to /var/log/auth.log.
authpriv.info /var/log/auth.log;SyslFormat
authpriv.* /var/log/auth.log;SyslFormat
Messages for authpriv at all levels will be logged to /var/log/auth.log.
authpriv.info /var/log/auth.log;SyslFormat
authpriv.none /var/log/auth.log;SyslFormat
No authpriv messages will be logged to /var/log/auth.log.
Also note this:
authpriv.info /var/log/auth.log;SyslFormat
authpriv.* /var/log/auth-copy.log;SyslFormat
Messages for authpriv at level info and above will be logged to /var/log/auth.log, and messages for authpriv at all levels will be logged to /var/log/auth-copy.log. So you get duplicated info and above messages.
authpriv.info /var/log/auth.log;SyslFormat
authpriv. /var/log/auth-copy.log;SyslFormat
Nothing is logged to /var/log/auth-copy.log.
Related
Using Firebase for authentication, I am seeing behavior that seems like extremely aggressive progressive lockout (after 1 or 2 failed attempts, having to wait 15 to 30 seconds to retry), yet I cannot find any documentation of such behavior or whether it is possible to modify it.
The specific behavior I am seeing is that if I submit a valid username but invalid password (using Firebase.auth.signInWithEmailAndPassword()), I will get auth/user-not-found results anywhere from 1 to 5 times, then I will start to receive auth/too-many-requests/TOO_MANY_ATTEMPTS_TRY_LATER
Once I receive this result, I can submit the valid password for the same account and will continue receiving the TOO_MANY_ATTEMPTS_TRY_LATER result until I wait a yet-undetermined amount of time (sometimes 15 seconds, other times up to a minute)
If instead, once I receive the TOO_MANY_ATTEMPTS_TRY_LATER result, I immediately submit a signInWithEmailAndPassword request for another account, they fail or succeed on their own accord - suggesting that the "lockout" is based on the account not my source IP or client.
Is this known and expected behavior? If so, is there anywhere to modify the aggressiveness of the lockout trigger? My users are getting confused because they are seemingly not being allowed into the app when they are certain they have gotten the correct password - many times after only a single failed password attempt.
Where can I configure the log level?
In our Plugin, we've got some logger.Debug("...") and logger.Information("...") but I'm only seeing the Information ones in the Admin site.
I assume the fix is changing the log level to Debug, no?
Yes, by design it's disabled, thus even if you change the log level from Information to Debug it won't make any difference, and you won't able see any log at admin area.
To write debug log you have to enable debug log level at Nop.Services.Logging> IsEnabled rebuild the solution and run it again.
To implement it with plugin, you would need to override IsEnabled method and switch as per user input.
There is an alternate way to write debug log instead:
_logger.InsertLog(Nop.Core.Domain.Logging.LogLevel.Debug, "debug info here");
I am trying to send a message through the command line using msg.exe on Windows 7. I have successfully gotten everything to work except for the Session ID. I get the error Error 5 getting session names. After searching online I found that I can edit the registry to remove this error using regedit.exe. However, on the domain I am on, I do not have permissions to edit the registry. I can only view it.
I know the individual session ID's of the users that I am trying to send a message to.
Super user hasn't really been any help... How do I prevent the error from occurring without editing the registry?
You need to log into the user, that the computer you are trying to send to is on.You will need to do is go to credential manager, and add the credentials. That error message will go away.
Is there any way of listening to a read on a reference?
E.g
user1 adds a readListener to ref/books/book1
user2 observes/reads ref/books/book1 and gets its value
user1's readListener is triggered
I haven't seen anything like it in Firebase yet, and I guess a workaround would be to have user2 set some ref/books/book1/read value, but I'm interested to hear if anyone has any other ideas.
Firebase is a fairly simple JSON database. There is nothing built-in to fire an event when another user has received specific data.
But as you indeed said, you can build something like that yourself. Most chat applications that need read-confirmation either do this per message or write a "last message ID that I received" marker.
The Goal
I would like only a certain group of users (who are in an Active Directory group composed of users from two domains) to be able to execute a web script, in http://www.site.org/protected, after being challenged for authentication.
The Setup
Windows 2008, IIS 7. User Account Access has been disabled, as it is a pain and sometimes causes perfectly reasonable things to fail. The server is part of a domain I will called LITTLEDOMAIN. We have a trust with BIGDOMAIN.
I have a group, called "LITTLEDOMAIN\can-use-this." In that group are the members LITTLEDOMAIN\me and BIGDOMAIN\me. I did the bit in Active Directory where the server now allows that group to authenticate against another domain (BIGDOMAIN).
The application pool for www.site.org runs as "NetworkService."
The dirctory has the user SYSTEM, the user NETWORK SERVICE, the group Enterprise Admins, and the group LITTLEDOMAIN\can-use-this with at least Read and Execute permissions.
In IIS 7, I have disabled all forms of authentication for that directory but Windows Authentication. As to Authorization Rules, All Users are Allowed.
The Error
When I use, say, FireFox, visit the URL http://www.site.org/protected, and am presented with a challenge, I can enter the username LITTLEDOMAIN\me and my password, then see the minimal HTML generated by my very simple Python script, which is basically a "Hello, World" with a timestamp thrown in so I can make sure caching of the page does not occur. If I use BIGDOMAIN\me, I receive an HTTP 500 error.
Diagnostics Performed
The passwords for LITTLEDOMAIN\me and BIGDOMAIN\me are the same; this has been checked.
I look in the HTTP logs and see the "500 0 267" for "sc-status sc-substatus sc-win32-status" in the HTTP logs. A "net helpmsg 267" from the command line gives me "The directory name is invalid."
I added Failed Request Tracing Rules and see the same unhelpful message in the XML: "The directory name is invalid. (0x8007010b)"
I have turned on file object auditing in the policy for that server, then set the auditing for the directory and the files within it to have all failures for "Everyone," but nothing shows up in the Security section of Event Viewer. I was able to cause other failures, so I know that failure auditing is working. This suggests that the system is not even getting to the point where the file is being accessed.
I gave, temporarily, the group LITTLEDOMAIN\can-use-this full control over the C:\TEMP directory, on the off chance this was in use. I recycled the application pool. The same error occurs. I tried this in C:\Windows\Temp as well, to no avail.
The Question
How can I find out "well, WHICH directory name is invalid?" It's pretty obvious that something, somewhere along the line, wants permissions for BIGDOMAIN, but I cannot figure out where.
The missing component, in addition to an audit policy and Failed Request Tracing, is Process Monitor. Not Process Explorer, but Process Monitor.
Run Process Monitor for three or so seconds, just long enough to get your request in, and have it fail. Use Failed Request Tracing to get the process ID that failed. Use Process Monitor's filter to show only events where the process ID appears -- you can then see where it fails.
Then set auditing on that directory to see what account is being used.
It appears that IIS 7 is returning to the root of the webserver when looking at a protected subdirectory. Odd.