PySNMP - default location of the compiled MIBs - pysnmp

I configured the compiler where to look for asn1 MIBs as follows:
compiler.addMibCompiler(mibBuilder, sources=['/usr/share/snmp/mibs'])
Then used getCmd() as:
errorIndication, errorStatus, errorIndex, varBinds = next(
getCmd(SnmpEngine(),
CommunityData('private', mpModel=0),
UdpTransportTarget(('192.168.56.20', '161')),
ContextData(),
ObjectType(ObjectIdentity('VLAN-MIB','InterfaceMode',3))))
I find VLAN-MIB.py in $HOME/.pysnmp/mibs and everything worked fine.
But I wanted to modify the asn1 MIBs location to my local folder. Say:
/home/krish/mibs
I tried it in 2 different ways:
This:
compiler.addMibCompiler(mibBuilder, sources=['/home/krish/mibs'])`
This:
errorIndication, errorStatus, errorIndex, varBinds = next(
getCmd(SnmpEngine(),
CommunityData('private', mpModel=0),
UdpTransportTarget(('192.168.56.20', '161')),
ContextData(),
ObjectType(ObjectIdentity('VLAN-MIB','InterfaceMode',3).addAsn1MibSource('/home/krish/mibs')))
)
Either way, I am getting error which says that VLAN-MIB could not be found.
But if I compile it myself offline and place the VLAN-MIB.py file in the specified directory as:
errorIndication, errorStatus, errorIndex, varBinds = next(
getCmd(SnmpEngine(),
CommunityData('private', mpModel=0),
UdpTransportTarget(('192.168.56.20', '161')),
ContextData(),
ObjectType(ObjectIdentity('VLAN-MIB','InterfaceMode',3).addMibSource('/home/krish/mibs')))
)
it worked fine.
So my question is where the compiled MIBs (.py) are placed after PySMI is automatically parses the asn1 MIBs? I did not find them in default location $HOME/.pysnmp/mibs in the above case.
and how do I tell pysnmp/pysmi where to keep the auto-generated .py file.
and I don't want to use addMibSource() in every get/set calls. addMibCompiler() worked fine only for the /usr/share/snmp/mibs, not for the user directories.
Wondering what I am missing here. Appreciate help.

My guesses are:
It is that ASN.1 MIB could not be found, not its compiled counterpart VLAN-MIB.py
It is not that ASN.1 VLAN-MIB could not be found, but some other ASN.1 MIB on which VLAN-MIB is dependent
What exactly pysnmp error says?
Since you work with ASN.1 MIBs, e.g. not pysmi pre-compiled ones, you should use .addMibCompiler or .addAsn1MibSource for setting up search path.
Despite its name, .addMibCompiler/.addAsn1MibSource do not add a path but set a new one(s) for given MibBuilder instance. Thus you should always specify all sources of MIBs your application might need for MIBs you refer to and for MIBs imported by those you refer to (and that goes recursively).
You can pass the destination keyword parameter to .addMibCompiler/.addAsn1MibSource functions to alter compiled MIBs location.
Having said that I'd propose to try:
addMibCompiler(mibBuilder, sources=['/home/krish/mibs', '/usr/share/snmp/mibs'])
or
ObjectType(ObjectIdentity('VLAN-MIB','InterfaceMode',3).addAsn1MibSource('/home/krish/mibs', '/usr/share/snmp/mibs')))
Alternatively, if you want to stick to just /home/krish/mibs, try copying all required MIBs into that directory. Import errors from pysnmp report missing dependencies.
Finally, there is a large collection of various MIBs on-line you could configure pysnmp to automatically download and use:
addMibCompiler(mibBuilder, sources=['http://mibs.snmplabs.com/asn1/#mib#'], destination='/home/krish/mibs')

Related

Copy all files with given extension to output directory using CMake

I've seen that I can use this command in order to copy a directory using cmake:
file(COPY "myDir" DESTINATION "myDestination")
(from this post)
My problem is that I don't want to copy all of myDir, but only the .h files that are in there. I've tried with
file(COPY "myDir/*.h" DESTINATION "myDestination")
but I obtain the following error:
CMake Error at CMakeLists.txt:23 (file):
file COPY cannot find
"/full/path/to/myDIR/*.h".
How can I filter the files that I want to copy to a destination folder?
I've found the solution by myself:
file(GLOB MY_PUBLIC_HEADERS
"myDir/*.h"
)
file(COPY ${MY_PUBLIC_HEADERS} DESTINATION myDestination)
this also works for me:
install(DIRECTORY "myDir/"
DESTINATION "myDestination"
FILES_MATCHING PATTERN "*.h" )
The alternative approach provided by jepessen does not take into account the fact that sometimes the number of files to be copied is too high. I encountered the issue when doing such thing (more than 110 files)
Due to a limitation on Windows on the number of characters (2047 or 8191) in a single command line, this approach may randomly fail depending on the number of headers that are in the folder. More info here https://support.microsoft.com/en-gb/help/830473/command-prompt-cmd-exe-command-line-string-limitation
Here is my solution:
file(GLOB MY_HEADERS myDir/*.h)
foreach(CurrentHeaderFile IN LISTS MY_HEADERS)
add_custom_command(
TARGET MyTarget PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CurrentHeaderFile} ${myDestination}
COMMENT "Copying header: ${CurrentHeaderFile}")
endforeach()
This works like a charm on MacOS. However, if you have another target that depends on MyTarget and needs to use these headers, you may have some compile errors due to not found includes on Windows. Therefore you may want to prefer the following option that defines an intermediate target.
function (CopyFile ORIGINAL_TARGET FILE_PATH COPY_OUTPUT_DIRECTORY)
# Copy to the disk at build time so that when the header file changes, it is detected by the build system.
set(input ${FILE_PATH})
get_filename_component(file_name ${FILE_PATH} NAME)
set(output ${COPY_OUTPUT_DIRECTORY}/${file_name})
set(copyTarget ${ORIGINAL_TARGET}-${file_name})
add_custom_target(${copyTarget} DEPENDS ${output})
add_dependencies(${ORIGINAL_TARGET} ${copyTarget})
add_custom_command(
DEPENDS ${input}
OUTPUT ${output}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${input} ${output}
COMMENT "Copying file to ${output}."
)
endfunction ()
foreach(HeaderFile IN LISTS MY_HEADERS)
CopyFile(MyTarget ${HeaderFile} ${myDestination})
endforeach()
The downside indeed is that you end up with multiple target (one per copied file) but they should all end up together (alphabetically) since they start with the same prefix ORIGINAL_TARGET -> "MyTarget"

Protobufs import from another directory

While trying to compile a proto file named UserOptions.proto which has an import named Account.proto using the below command
protoc --proto_path=/home/project_new1/account --java_out=/home/project_new1/source /home/project_new1/settings/Useroptions.proto
I get the following error :
/home/project_new1/settings/UserOpti‌​ons.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file.
PS: UserOptions.proto present in the directory /home/project_new1/settings
imports Account.proto present in the directory
/home/project_new1/account
Proto descriptor files:
UserOptions.proto
package settings;
import "Account.proto";
option java_outer_classname = "UserOptionsVOProto";
Account.proto
package account;
option java_outer_classname = "AccountVOProto";
message Object
{
optional string userId = 1;
optional string service = 2;
}
As the error message states, the file you pass on the command line needs to be in one of the --proto_paths. In your case, you have only specified one --proto_path of:
/home/project_new1/
But the file you're passing is:
/home/project_new1/settings/UserOpti‌ons.proto
Notice that the file is not in the account subdirectory; it's in settings instead.
You have two options:
(Not recommended) Pass a second --proto_path argument to add .../settings to the path.
(Recommended) Use the root of your source tree as the proto path. E.g.:
protoc --proto_path=/home/project_new1/ --java_out=/home/project_new1 /home/project_new1/settings/UserOpti‌ons.proto
In this case, to import Account.proto, you'll need to write:
import "acco‌​unt/Account.proto";
For those of us who want this really spelled out, here is an example where I have installed the protoc beta for gRPC using NuGet Packages Google.Protobuf, Grpc.Core and Grpc.Tools. My solution packages are one level above my Grpc directory (i.e. at BruTrader\packages). My .proto files are at BruTrader\Grpc\protos.
1. My .proto file:
syntax = "proto3";
import "timestamp.proto";
import "enums.proto";
package BruTrader.Grpc;
message DividendMessage {
double amount = 1;
google.protobuf.Timestamp dateUnix = 2;
}
2. my GenerateProto.bat file:
..\packages\Google.Protobuf.3.0.0-beta2\tools\protoc.exe -I..\Grpc\protos -I..\packages\Google.Protobuf.3.0.0-beta2\tools\google\protobuf --csharp_out=..\Grpc\Generated --grpc_out=..\Grpc\Generated --plugin=protoc-gen-grpc=..\packages\Grpc.Tools.0.13.0\tools\grpc_csharp_plugin.exe %1
3. my BuildProtos.bat
call GenerateProto ..\Grpc\protos\masterinstrument.proto
call GenerateProto .\protos\instrument.proto
etc.
4. BuildProtos.bat is executed as a Pre-build event on my Grpc project like this:
CD $(ProjectDir)
CALL "$(ProjectDir)BuildProtos.bat"
For my environment, Windows 10 Pro operating system and C++ programming languaje, I used the protoc-3.12.2-win64.zip that you can downloat it from here. You should open a Windows PowerShell inside the protoc-3.12.2-win64\bin path and then you must execute one of the next commands:
.\protoc.exe -I=C:\Users\UserName\Desktop\SRC --cpp_out=C:\Users\UserName\Desktop\DST C:\Users\UserName\Desktop\SRC\addressbook.proto
Or
.\protoc.exe --proto_path=C:\Users\UserName\Desktop\SRC --cpp_out=C:\Users\UserName\Desktop\DST C:\Users\UserName\Desktop\SRC\addressbook.proto
Note:
1- My source folder is in: C:\Users\UserName\Desktop\SRC
2- My destination folder is in: C:\Users\UserName\Desktop\DST
3- My .proto file is in: C:\Users\UserName\Desktop\SRC\addressbook.proto

Automake, generated source files and VPATH builds

I'm doing VPATH builds with automake. I'm now also using generated source, with SWIG. I've got rules in Makefile.am like:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
Then the file gets used later:
myprogram_SOURCES = ... whatever.cpp
It works fine when $builddir == $srcdir. But when doing VPATH builds (e.g. mkdir build; cd build; ../configure; make), I get error messages about missing whatever.cpp.
Should generated source files go to $builddir or $srcdir? (I reckon probably $builddir.)
How should dependencies and rules be specified to put generated files in the right place?
Simple answer
You should assume that $srcdir is a read-only, so you must not write anything there.
So, your generated source-code will end up in $(builddir).
By default, autotool-generated Makefiles will only look for source-files in $srcdir, so you have to tell it to check $builddir as well. Adding the following to your Makefile.am should help:
VPATH = $(srcdir) $(builddir)
After that you might end up with a no rule to make target ... error, which you should be able to fix by updating your source-generating rule as in:
$(builddir)/whatever.cpp: whatever.swig
# ...
A better solution
You might notice that in your current setup, the release tarball (as created by make dist) will contain the whatever.cpp file as part of your sources, since you added this file to the myprogram_SOURCES.
If you don't want this (e.g. because it might mean that the build-process will really take the pregenerated file rather than generating it again), you might want to use something like the following.
It uses a wrapper source-file (whatever_includer.cpp) that simply includes the generated file, and it uses -I$(builddir) to then find the generated file.
Makefile.am:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
whatever_includer.cpp: whatever.cpp
myprogram_SOURCES = ... whatever_includer.cpp
myprogram_CPPFLAGS = ... -I$(builddir)
clean-local::
rm -f $(builddir)/whatever.cpp
whatever_includer.cpp:
#include "whatever.cpp"
Usually, you want to keep $srcdir readonly, so that if for instance the source is distributed unpacked on a CDROM, you can still run /.../configure from some other part of the file-system.
However if you are using SWIG to generate source code for a wrapper library, you probably want to distribute that SWIG-generated code as well so that your users do not need to install SWIG to compile your code. Then you have indeed a choice: you can decide that the SWIG-generated code should end in $builddir (it's OK: make dist will collect it there and include it in the tarball), or you could decide to output SWIG-generated code in $srcdir since it is really a source from the point of view of the distributed package. An advantage of keeping it in $srcdir is that when make distcheck attempts to build your package from a read-only source directory, it will fail on any attempt to call SWIG to regenerate the wrapper source. If you have your wrapper source in $builddir, you might not notice you have some broken rule that cause SWIG to be run on the user's host; by generating in $srcdir you ensure that SWIG is not needed by your users.
So my preference is to output SWIG wrapper sources in $srcdir. My setup for Python wrappers looks as follows:
EXTRA_DIST = spot.i
python_PYTHON = $(srcdir)/spot.py # _PYTHON is distributed by default
pyexec_LTLIBRARIES = _spot.la
MAINTAINERCLEANFILES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot.py
_spot_la_SOURCES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot_wrap.h
_spot_la_LDFLAGS = -avoid-version -module
_spot_la_LIBADD = $(top_builddir)/src/libspot.la
$(srcdir)/spot_wrap.cxx: $(srcdir)/spot.i
$(SWIG) -c++ -python -I$(srcdir) -I$(top_srcdir)/src $(srcdir)/spot.i
# Handle the multi-file output of SWIG.
$(srcdir)/spot.py: $(srcdir)/spot.i
$(MAKE) $(AM_MAKEFLAGS) spot_wrap.cxx
Note that I use $(srcdir) for all targets, because of limitations of the VPATH feature on various flavors of make. My setup to deal with the multiple files output by SWIG could be improved, but as these rules are not run by users and it has never caused me any problem, I do not bother.

CMakeLists.txt for Eclipse and ROS

I have been doing a project that has many classes (including cpp and header files) and one executable cpp that has int main. With ROS, I'm trying to link these with CMakeLists.txt and with the runtime, I'm planning to compile it without having to change the txt every time. Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)
rosbuild_init()
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
rosbuild_add_library(${PROJECT_NAME} Im_Basibos.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_HedefeGitme.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Konum.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Robot.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Sonar.cpp)
rosbuild_add_executable(srctest Im_RobotKontrol.cpp)
I dont know how to link the header files, I have to link these:
Im_Basibos.h, Im_Basibos.cpp
Im_HedefeGitme.h, Im_HedefeGitme.cpp
Im_Konum.h, Im_Konum.cpp
Im_Robot.h, Im_Robot.cpp
Im_Sonar.h, Im_Sonar.cpp
and
Im_Robot.cpp that has int main()
Any answer will be much appreciated. Thanks already..
I guess rosbuild_add_library works the same than add_library and is not meant to works the way you're using it. It's meant to create static or shared libraries, not to build object files.
I'm giving you two possible ways to build your executable.
version 1
If you only need to build an executable srctest and no separate library.
What you need to do is to list your source files in some variables, say srctest_SOURCES:
set(srctest_SOURCES Im_Basibos.cpp Im_HedefeGitme.cpp
Im_Konum.cpp Im_Robot.cpp Im_Sonar.cpp
Im_RobotKontrol.cpp)
Then build those sources into an executable:
add_executable(srctest ${srctest_SOURCES})
version 2
Now, if you really want to first build a library, say testlib then link it to your srctest executable, that can be done too:
set(testlib_SOURCES Im_Basibos.cpp Im_HedefeGitme.cpp
Im_Konum.cpp Im_Robot.cpp Im_Sonar.cpp)
add_library(testlib ${srctest_SOURCES})
add_executable(srctest Im_RobotKontrol.cpp)
target_link_libraries(srctest testlib)
Thanks to Guillaume for the methods,
Since I'm working with ROS environment,
the exact commands that did the trick were:
rosbuild_add_library(${PROJECT_NAME} Im_Basibos.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_HedefeGitme.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Konum.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Robot.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Sonar.cpp)
rosbuild_add_executable(srctest Im_RobotKontrol.cpp)
target_link_libraries(srctest ${PROJECT_NAME})

Is there a way to tell django compressor to create source maps

I want to be able to debug minified compressed javascript code on my production site. Our site uses django compressor to create minified and compressed js files. I read recently about chrome being able to use source maps to help debug such javascript. However I don't know how/if possible to tell the django compressor to create source maps when compressing the js files
I don't have a good answer regarding outputting separate source map files, however I was able to get inline working.
Prior to adding source maps my settings.py file used the following precompilers
COMPRESS_PRECOMPILERS = (
('text/coffeescript', 'coffee --compile --stdio'),
('text/less', 'lessc {infile} {outfile}'),
('text/x-sass', 'sass {infile} {outfile}'),
('text/x-scss', 'sass --scss {infile} {outfile}'),
('text/stylus', 'stylus < {infile} > {outfile}'),
)
After a quick
$ lessc --help
You find out you can put the less and map files in to the output css file. So my new text/less precompiler entry looks like
('text/less', 'lessc --source-map-less-inline --source-map-map-inline {infile} {outfile}'),
Hope this helps.
Edit: Forgot to add, lessc >= 1.5.0 required for this, to upgrade use
$ [sudo] npm update -g less
While I couldn't get this to work with django-compressor (though it should be possible, I think I just had issues getting the app set up correctly), I was able to get it working with django-assets.
You'll need to add the appropriate command-line argument to the less filter source code as follows:
diff --git a/src/webassets/filter/less.py b/src/webassets/filter/less.py
index eb40658..a75f191 100644
--- a/src/webassets/filter/less.py
+++ b/src/webassets/filter/less.py
## -80,4 +80,4 ## class Less(ExternalTool):
def input(self, in_, out, source_path, **kw):
# Set working directory to the source file so that includes are found
with working_directory(filename=source_path):
- self.subprocess([self.less or 'lessc', '-'], out, in_)
+ self.subprocess([self.less or 'lessc', '--line-numbers=mediaquery', '-'], out, in_)
Aside from that tiny addition:
make sure you've got the node -- not the ruby gem -- less compiler (>=1.3.2 IIRC) available in your path.
turn on the sass source-maps option buried away in chrome's web inspector config pages. (yes, 'sass' not less: less tweaked their debug-info format to match sass's since since sass had already implemented a chrome-compatible mapping and their formats weren't that different to begin with anyway...)
Not out of the box but you can extend a custom filter:
from compressor.filters import CompilerFilter
class UglifyJSFilter(CompilerFilter):
command = "uglifyjs -c -m " /
"--source-map-root={relroot}/ " /
"--source-map-url={name}.map.js" /
"--source-map={relpath}/{name}.map.js -o {output}"