My problem is that when I add a printer using the Printers and Scanners UI printing works, when I add the same printer using lpadmin it doesn't.
To Add it through the UI I did the following:
From Printers and Scanners I selected the IP tab.
Address: 10.20.30.40, Protocol HP Jetdirect - Socket, Queue left blank, Name: TEST_01, Location "Top Floor", Use -> Select software -> HP LaserJet P3010 Series
After doing this, the Printer works as expected.
This is a (segment from a) script containing my lpadmin command that doesn't work
SUBNET=socket://10.20.30.
TEST_01=40
PPD_DIR=/Library/Printers/PPDs/Contents/Resources
TEST_01_PPD="hp LaserJet P3010 Series.gz"
lpadmin -E -p TEST_01 -v $SUBNET$TEST_01 -P "$PPD_DIR/$TEST_01_PPD" -D "TEST_01" -L "Top Floor"
The printer appears correctly in the UI but shows as paused.
I did find a message in system.log that may or may not be relevant - I was using Notes to test the printer:
Notes[502]: Failed to connect (_delegate) outlet from (com_hp_psdriver_19_11_0_PDEView) to (com_hp_psdriver_19_11_0_PDEAccountingController): missing setter or instance variable
Notes[2198]: Printing failed because PMSessionEndDocumentNoDialog() returned -30871.
The reason I want to use a script is that there are 20 printers to add on each of 30 new Macs. The actual script uses a series of arrays with lpadmin in a for loop. Everything I have read says it should work. What am I missing?
I think -E specified before the printer name enables encryption, whereas specified after it Enables the printer - effectively "unpausing" it. Madness- I know!
Mad Apple Documentation - see second sentence
I think you want:
lpadmin -p TEST_01 -v $SUBNET$TEST_01 -P "$PPD_DIR/$TEST_01_PPD" -D "TEST_01" -L "Top Floor" -E
I don't have a direct answer, but I can suggest an alternate approach: set up all 20 printers by hand on one computer, then copy the /etc/cups directory from that one to the other 29.
Related
In this thread I received some assistance with getting this script to work correctly. The script essentially sets my network location according to the SSID I'm connected to. This is now working, however, it generates a lot of nuisance notifications.
Every time my laptop joins a wifi network, the script runs, sets the network location, and gives me a notification. Since power nap periodically joins the wifi to check for emails/updates and what have you, after a long weekend I'll get dozens of identical notifications.
How can I modify the script so that it only send a notification if the network location is changed to something different, not just when the script runs? Can I somehow check the existing network location and only change it/trigger a notification if the "new" location is different to the "existing" location?
Again, I'm extremely new to scripting on mac and GitHub in general; my previous experience is all on Windows and largely self taught.
Script:
#!/bin/bash
# automatically change configuration of Mac OS X based on location
# redirect all IO to a logfile
mkdir -p /usr/local/var/log
exec &>/usr/local/var/log/locationchanger.log
# get a little breather before we get data for things to settle down
sleep 2
# get SSID
SSID=$(/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I | sed -n 's/^ *SSID: //p')
echo $(date) "New SSID found: $SSID"
# LOCATIONS
LOCATION=
Location_Automatic="Automatic"
Location_Office="Office"
Location_Site="Site"
# SSIDS
SSID_Office="My Office SSID"
SSID_Site="My Mobile SSID"
# SSID -> LOCATION mapping
case $SSID in
"$SSID_Office") LOCATION="$Location_Office";;
"$SSID_Site" ) LOCATION="$Location_Site";;
esac
REASON="SSID changed to $SSID"
# Location_Automatic
if [ -z "$LOCATION" ]; then
LOCATION="$Location_Automatic"
REASON="Automatic Fallback"
fi
# change network location
scselect "$LOCATION"
case $LOCATION in
"$Location_Automatic" )
osascript -e 'display notification "Network Location Changed to Automatic" with title "Network Location Changed"'
;;
"$Location_Office" )
osascript -e 'display notification "Network Location Changed to Office" with title "Network Location Changed"'
;;
"$Location_Site" )
osascript -e 'display notification "Network Location Changed to Site" with title "Network Location Changed"'
;;
esac
echo "--> Location Changer: $LOCATION - $REASON"
exit 0
This thread explains how to get the current network location.
I added the following code to get the current network location before making any changes:
CurrLoc=$(scselect | awk '{if ($1=="*") print $3}' | sed 's/[()]//g')
And then a simple if statement to exit the script early if the evaluated "new" network location matched the existing one:
if [ "$CurrLoc" = "$LOCATION" ]
then
exit 0
fi
# existing code to change network location and show notifications
Given the following sample/simple snmpd.conf (Net-SNMP 5.7.2 on RHEL 7.4)
rwcommunity private 192.168.56.101
trapsess -Ci --clientaddr=192.168.56.128 -v 2c -c private 192.168.56.101:162
when starting a SNMP Daemon
snmpd -f -Lo -D -C -c data/snmpd_test.conf udp:192.168.56.128:161
We obtain ''Start Up'' InformRequest with IP source 192.56.168.1 instead of ...128 (WireShark snapshot below)
It is not surprising as the -D option allows us to output the debug information saying that
trace: netsnmp_config_process_memory_list(): read_config.c, 696:
read_config:mem: processing memory: clientaddr 192.168.56.128
trace: run_config_handler(): read_config.c, 562:
9:read_config:parser: clientaddr handler not registered for this time
Web sources however say:
snmp.conf
...This value is also used by snmpd when generating notifications.
snmpd.conf
trapsess [SNMPCMD_ARGS] HOST
provides a more generic mechanism for defining notification destinations.
SNMPCMD_ARGS should be the command-line options required for an equivalent
snmptrap (or snmpinform) command to send the desired notification
I read also some old threads like this one
However this option is working well with snmptrap
snmptrap -D -Lo -Ci --clientaddr=192.168.56.128 -M+path_to_my_mibs -v 2c -c private 192.168.56.101:162 "" .1.3.6.1.4.1.a.b.c.d.e.f.0 i 0
This option is also working when placed in snmp.conf ( mind there is no 'd' here ) and then it applies to snmpset and snmpget (and maybe other)
So my question is: Is it a documentation error, a bug, a misuse of the Net-SNMP stack ?
After a long struggle I may have an answer and I write a short note as I just found a trick
It seems that clientaddr is not parsed correctly wherever in the snmpd.conf
(I tried not also inside the trapsess line)
But it seems to be a valid option in the command line of snmpd
like it was a valid option in the snmptrap command line. So I assumed it could be the same parsing mechanism for both.
a condition also is that the IP addres must be valid one
which means that
snmpd -f -Lo -D -C -c data/snmpd_test.conf --clientaddr=192.168.56.128 udp:192.168.56.128:161
seems to fully solve my problem.
I will perform more tests and if accurate format this answer a little bit better but it seems a good hint.
Okay, hopefully I can explain this correctly as I have no idea what's causing this or how to resolve this.
For some reason bash commands (on a CentOS 6.x server) are displaying more information than "normally" and that causes issues with certain scripts. I have no clue if there is a name for this, but hopefully someone knows a solution for this.
First example.
Correct / good server:
[root#goodserver ~]# vzctl enter 3567
entered into CT 3567
[root#example /]#
(this is the correct behaviour)
Incorrect / bad server:
[root#badserver /]# vzctl enter 3127
Entering CT
entered into CT 3127
Open /dev/pts/0
[root#example /]#
With the "bad" server it will display more information as usual, like:
Entering CT
Open /dev/pts/0
It's like it parsing extra information on what it's doing.
Ofcourse the above is purely something cosmetic, however with several bash scripts we use, these issues are really issues.
A part of the script we use, uses the following command (there are more, but this is mainly a example of what's wrong):
DOMAIN=`vzctl exec $VEID 'hostname -d'`
The result of the above information is parsed in /etc/named.conf.
On the GOOD server it would be added in the named.conf like this:
zone "example.com" {
type master;
file "example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
The above is correct.
On the BAD server it would be added in the named.conf like this:
zone "Executing command: hostname -d
example.com" {
type master;
file "Executing command: hostname -d
example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
So it's add stuff of the action it does, in this example "Executing command: hostname -d"
Another example here when I run the command on a good server and on the bad server.
Bad server:
[root#bad-server /]# DOMAIN=`vzctl exec 3333 'hostname -d'`
[root#bad-server /]# echo $DOMAIN
Executing command: hostname -d example.com
Good server:
[root#good-server ~]# DOMAIN=`vzctl exec 4444 'hostname -d'`
[root#good-server ~]# echo $DOMAIN
example.com
My knowledge is limited, but I have tried several things checking rsyslog and the grub.conf, but nothing seems out of the ordinary.
I have no clue why it's displaying the extra information.
Probably it's something simple / stupid, but I have been trying to solve this for hours now and I really have no clue...
So any help is really appreciated.
Added information:
Both servers use: kernel.printk = 7 4 1 7
(I don't know if that's useful)
Well (thanks to Aaron for pointing me in the right direction) I finally found the little culprit which was causing all the issues I experienced with this script (which worked for every other server, so no need to change that obviously).
The issues were caused by the VERBOSE leven set in vz.conf (located in /etc/vz/ directory). There is an option in there called "VERBOSE" and in my case it was set to 3.
According to OpenVZ's website it does the following:
Increments logging level up from the default. Can be used multiple times.
Default value is set to the value of VERBOSE parameter in the global
configuration file vz.conf(5), or to 0 if not set by VERBOSE parameter.
After I changed VERBOSE=3 to VERBOSE=0 my script worked fine once again (as it did for every other server). :-)
So a big shoutout to Aaron for pointing me in the right direction. The answer is easy when you know where to look!
Sorry to say, but I am kinda disappointed by ndim's reaction. This is the 2nd time he was very unhelpful and rude in his response after that. He clearly didn't read the issue I posted correctly. Oh well.
I would make sure to properly parse the output of the command. In this case, we are only interested in lines of the form
entered into CT 12345
One way of doing this would be to pipe everything through sed and having sed print only the number when the line looks as above (untested, and I always forget which braces/brackets/parens need a backslash in front of them):
whateverthecommand | sed -n 's/^entered into CT ([0-9]{1,})$/\1/p'
I am using UFTP to transfer files within the subnetwork computers.
But when I used -H to send only particular computers instead of sending to all computers, it is not working as expected.
Let me explain in detail :
I have two windows machines in same network of IP's 172.21.170.198,172.21.181.216 respectively.
From one of the system, I used below mentioned command to send the file
uftp.exe -R 100000 -H 172.21.170.198,172.21.181.216 e:\setup.exe
But both machines won't receive those file.
But if I use this command both machines will receive the file.
uftp.exe -R 100000 E:\setup.exe
I want to know whether I made any mistake.
Please correct me if I am wrong.
Thanks in Advance.
Kindly revert back for any clarifications.
Regards,
Thiyagu
If ipv6 isn't enabled, it would look like this, converting the ipv4 addresses to hex (with a converter like http://www.kloth.net/services/iplocate.php):
uftp.exe -R 100000 -H 0xAC15AAC6,0xAC15B5D8 e:\setup.exe
But if you have an ipv6 address on the client, the client id sort of comes from the end of it backwards. Like if the address was "fe80::e5ca:e3ca:fea3:153f%5", the command would look like:
uftp.exe -R 100000 -H 0x3f15a3fe e:\setup.exe
(coming from "fe a3 15 3f")
I'm trying to get pf working under Mountain Lion. Since it appears that Apple neglected to include pflogd, we have to make our own like:
/sbin/ifconfig pflog0 create
/usr/sbin/tcpdump -lnettti pflog0 | /usr/bin/logger -t pf
This dumps messages into system.log, but I'm trying to find a way to sort them out into their own. I was able to figure this out with ipfw, but ipfw left nice logs like:
Mar 5 11:34:44 flamingo kernel[0] <Debug>: ipfw: 65534 Deny ICMP:3.10 192.168.4.233 192.168.92.60 in via en0
For pf, I'm getting logs like:
Mar 5 11:57:50 flamingo.mydomain.com pf[51938]: 00:00:00.000000 rule 1/8(ip-option): pass in on en0: 172.24.32.41 > 224.0.0.1: igmp query v2
With OSXes 'logger', I can use -p to set a facility, but then the logs quietly vanish. I found references to using 'syslog -s -k facility whatever', but when I pipe my tcpdump into syslog, the process dies after a few seconds or minutes.
How can I A) find out how to keep syslog running, or B) either set or predict what I could filter the results from logger in asl.conf?
You're missing one ingredient to get logging.
This worked for me:
root# touch /var/log/pffirewall.log` to create the log file.
Then, add the following line to /etc/syslog.conf:
local2.* /var/log/pffirewall.log
Now your logger process output will show up in /var/log/pffirewall.log. Apparently logger is still tied to the old syslog facility and /etc/syslog.conf.