Is there a way to obtain flags of the IPV6 routing table through any API in Linux?
Netlink socket doesn't show any place for flags.
After checking route command's source code in net-tools it seems that it reads route from proc filesystem, i am wary of doing this, as it seems to be OS flavor dependent.
/proc is a and emplementation of procfs for Linux originally introduced in 1992. Every effort is made to maintain compatibility with applications using the filesystem. Including for alternative operating systems such as FreeBSD that provides a linprocfs filesystem to maintain binary compatibility with Linux applications.
The same software for net-tools is used on all major Linux systems, so there should be no issues with using those /proc files for system information.
Related
I had this question on my exam, now in diagrams I saw, we have : hardware, kernel, system call interface to the kernel, then (compilers, shells, sys.libs) and on top some applications. Does OS scope include only kernel, and everything else is just some additional functions we choose to install , or does a Unix OS include everything from the list I gave above?
OS have more or less 2 definitions :
academic : OS is soft for doing a abstraction layer between
hardware and software
pragmatic : OS is soft that come with hardware when we buy it.
Compiler and shell don't enter in definition 1. It can be enter in definition 2.
And usually, users that are interesting by a compiler or a shell prefer to consider OS as asbtraction layer (academic definition).
Simple answer, No. They are not an internal part of Unix but additional functionality to help make the Operating System more usable.
The OS scope applies primarily to the kernel only.
Whilst you need a compiler to build the kernel, you don't necessarily require one for the general day to day use of the system. Most operating systems don't ship the compiler by default and instead, the kernel and applications is built on one machine and then the resulting binarys are packaged and distributed either with the computer directly (Windows/Unix) or via the internet for others to download and install (Linux/BSD)
Likewise with the shell. Although all operating systems ship with a default one (sh/bash/dash on Linux|Unix systems, Command Prompt/Powershell on Windows), most general users can go their entire lives without using it.
Having said that, if you were to delete the shell, you'll almost certainly find your system won't boot up. This is because a lot of core start-up scripts rely on the shell to stop / start the services presenting interfaces between the user and the kernel.
In summary:
You need a compiler to build the kernel and applications but not for running the OS.
You need a shell to execute applications (which also includes the compiler)
I'm looking for a way to develop some Unix scripts that will connect to a DOS box (Windows server 2012) and interactively execute DOS commands.
I'm comfortable with the Unix side (I'll almost certainly use Expect), but I'm "Windows illiterate" and am unable to find anything about connecting to Windows's DOS command line in this fashion. Is this even possible to do?
(FWIW, this is to enable us to control Tableau Server using its 'tabcmd' DOS command suite from our existing Linux environment.)
UPDATE 1:
I think another way of asking the question is: does Windows provide anything that is the equivalent of the Unix "remote shell", accessible from Unix?
There are no built-in tools to do this, although PsExec is a utility that can almost do what you want. PsTools are not a built-in, but are hosted on Technet. Some things to keep in mind:
PsExec works by actually remotely copying a file over to the Windows System32 folder (copying is one thing that is builtin ;)
Windows uses Kerberos for authentication. This depends on the computer you are running the command from being on the same Active Directory as the computer you want to control, with access set up from that side. Linux can use kerberos through third-party AD integration tools (like Quest Authentication Services, a commercial product), or also Centrify but there are no built-in tools that do it.
Psexec is not encrypted, meaning if you send commands containing sensitive data, they can be seen (though not the authentication part of it).
PsExec is obviously still a Windows utility. I have been able to get it to work using Wine, but only for a local account and after some tweaking with matching hostnames and stuff. It's possible that if you have authenticated using QAS or Centrify that your wine command will somehow pick it up, but I haven't tested it; I don't work where we use AD anymore.
Maybe the biggest problem is the difference of philosophy between the two communities. Windows doesn't use command line execution very often for remote administration. There is more focus on using your local utilities on a remote system (i.e., you can load a remote registry hive from RegEdit or browse the file system of a remote system using your local Windows Explorer program).
Overall, I think Keith's solution is actually the best, and the most straightforward.
I've read that Windows 7 Enterprise and Ultimate
support the running of Unix commands. How does
the system cater towards this functionality?
Does it have a shell? What file formats does
it recognize? ELF, a.out, etc? Does it have
any Unix libraries installed? Any BSD (or GPL?) code?
Here it is: http://www.cygwin.com/
"Cygwin is a collection of tools which provide a Linux look and feel environment for Windows."
"It is a DLL (cygwin1.dll) which acts as a Linux API layer providing substantial Linux API functionality."
There are several tools already and you can try to compile what you need if it's missing.
Read FAQ: http://cygwin.com/faq-nochunks.html#faq.what
I have some questions:
Is it possible to install openstack on a Notebook with a 4GB DD3 Ram? Because the website says it needs atleast 8GB of RAM.
They say it requirs a double-QuadCore , I assue that means Octacore. Can we install that on a Quadcore?
They say that there is no possibility to install it on a NAS . Did you find any where if there is a possibility to do?. I dint find any even after asking our friend(google).
All in all, is it at-all possible to install on it a notebook/Desktop?
That advice is for production environments,
so 1)If you just want to play around your notebook will do fine. I had a succesful test-run on a 1.2 Ghz 1GB Netbook. It became incredibly slow when it launched it's first instance...
With a Double Quadcore they actually mean two seperate Quad-cores, as in two quad-core xeon processors on a single motherboard
So 2) yes you can install it on a quad-core.
3) a NAS device running openstack an openstack storage service seems to be unlikely indeed. You will most likely need more computing power.However If your NAS supports NFS or SSH or sth you can probably mount this drive and use it for storage.
4) You can perfectly build a all-in-one openstack test setup on your notebook. Performance will be low, but acceptable for testing.
It depends on what you mean by "install OpenStack". OpenStack itself is an extremely modular framework consisting on many services (Compute, Networking, Image service, Block Storage, Object Storage, Orchestration, Telemetry, ...). On top of that, a typical production deployment of OpenStack also requires several components, like load balancers, caching systems, firewalls, web servers and others. It is definitely possible to install a minimal openstack system, even on an average laptop.
The simplest way to run OpenStack on a laptop/desktop is to use Devstack, a shell script that installs all services from source and run them (by default) on a single machine. It is customizable enough to provide very good testing ground; it's used by OpenStack developers as well as the OpenStack QA team to test latest developments against "real" systems.
To avoid messing up your system, it's generally recommended to install OpenStack in a VM. From devstack doc:
DevStack should run in any virtual machine running a supported Linux release. It will perform best with 2Gb or more of RAM.
As of the time of this writing (Jan 2015), supported distros are:
Ubuntu (latest LTS)
Fedora
CentOS
Regarding NAS: you can of course use it, but "outside" Openstack apis, by providing mount points to your vms. It's even mandatory if you want to support live migration.
When I try to connect to local ports, Computer -> Connect local, using Portmon v. 3.02, I'm getting an error message, Error 2, in a small error dialog box:
I run the tool as an administrator (if not, I get error 6).
By the way this is a Windows 7 x64. On 32-bit, in Windows 7 x86, it works fine. How can I fix this problem?
Sysinternals' Portmon works only on 32-bit versions of Windows. It does not support 64-bit (probably its driver is not signed).
From the Portmon homepage:
Runs on:
Client: Windows XP (32-bit) and higher (32-bit).
Server: Windows Server 2003 (32-bit) and higher (32-bit).
In Windows Explorer, right click on portmon.exe --> select Properties --> click the Compatibility tab, and Run in Windows XP compatibility mode. It works fine like that in Windows 7 64-bit.
"Error 2" is "Cannot find the file specified", that is, cannot find a required DLL file.
Originally, you got this error when you tried to run Portmon from a network location: that broke the security trust, causing Portmon to be untrusted (or perhaps just messing up the search path somehow).
On my copy of Windows 7 64 bit, Microsoft Dependency Walker (depends.exe) tells me that PORTMSYS.SYS (the file created/loaded by Portmon.exe), has unresolved dependencies on ci.dll, clfs.sys, hal.dll and kdcom.dll.
Those are the
code integrity
common log file system
hardware abstraction layer
kernel debugger com
libraries, and they aren't actually missing: if they were, Windows wouldn't boot. However, I don't see a copy of those files in SysWow64. This suggests to me that the problem is not with portman.sys: the problem is with the win32 compatibility layer in Windows 7/64 bit: It doesn't support debug properly.
It is now 2018. There is no 64-bit version of Portmon. Serial ports are a legacy standard. The Windows 7 problem was fixed by the release of Windows 8.1. However, there is a faint chance that some Visual Studio utility or security update back-ported to Windows 7 will fix the problem. Perhaps someone who is familiar with SysWow and debugging will comment.
Instead of portmon for Windows x64, you can use an emulator of a pair of virtual COM ports and a simple program that will connect the physical port and one of the virtual ones, as well as perform the logging function.
To create a pair of virtual COM ports you can use:
com0com (preferably version "com0com-2.2.2.0-x64-fre-signed", because it contains signed x64 driver)
Virtual Serial Ports Emulator (VSPE), every time it starts on x64 it asks to purchase a driver, but it works even if you refuse.
Simple mapping and logging program can be found e.g. here or you can write it yourself, it is simple.
The sequence of actions is follows:
Сreate a pair of virtual COM ports using emulator (for example, COM28 and COM29)
Let the external device be connected to the computer COM1 port. In the program, whose exchange with external device we want to listen to, we set up a port COM28 (instead of СОМ1) for communication.
In the mapping program, we set up that we want to bind and log ports COM1 and COM29 (don't forget to set the port baud rate).
I haven't tried it yet, but this question mentions com0com. It creates two virtual serial ports and emulates a null modem cable between them. It claims to be able to run on 64 bit Windows. I'm not sure whether it comes with software that lets you just pipe input from a real port into one of the virtual ports. One of the FAQ's says that you can turn on logging.
I guess in the worst case, you could write your own small program that pipes data from a real port to one of the virtual ports and logs it all.
There's also this question on open-source alternatives that mentions a couple of projects.
I've used AccessPort
http://sudt.com/en/ap/download.htm and it works great. Very similar to Portmon
Don't start Portmon from a network drive/path or something else.
Copy on to the hard disk drive, e.g. on the desktop, restart and try again!
If you run Portmon in compatibility mode, it will work.
Check Make older programs run in this version of Windows.
It says:
To run the Program Compatibility troubleshooter:
Open the Program Compatibility troubleshooter by clicking the Start button Picture of the Start button, and then clicking Control Panel. In the search box, type troubleshooter, and then click Troubleshooting. Under Programs, click Run programs made for previous versions of Windows.
Follow the instructions in the troubleshooter.
The above is a public explanation from Microsoft for a common situation when running older applications in Windows.
But, I can say it briefly;
Right click on portmon.exe
Select menu about "troubleshooting compatibility problem" or something like that (I'm using a foreign version of Windows, so I don't see correct name of that menu in English.)
Select automatic mode
It will detect the problem and recommend Windows XP (SP2) mode
Select it and execute Portmon again.
I hope it works!
Instead of Portmon you can also use the IO Ninja program with the "Serial Monitor" plugin.
It gives a little less information than Portmon, but in a more understandable form. The main thing is, just like a Portmon, it allows you to see the data that is transmitted between a third-party application and an external device via a serial port. The program works under modern versions of Windows (I tried it myself on Windows 10 x64). The aforementioned plugin "Serial Monitor" is paid (but has an evaluation period).
Note: the port that you want to monitor must first be connected to the "IO Ninja" program, and then opened in a third-party application whose exchange with an external device you want to track.
Just to test that the hardware is working, you could perhaps boot a Linux live CD and run the statserial and/or minicom program to verify that it works. The Knoppix distribution seems to contain both those programs.
Serial ports on Linux are named /dev/ttyS0 for COM1, /dev/ttyS1 for COM2, etc.