How to keep X11 display after su or sudo - MobaXterm
I have received a lot of emails asking how to keep X11-forwarding working after changing user to root inside a SSH session in MobaXterm. This is by default not allowed on Unix/Linux systems, because the X11 display connection belongs to the user you used to log with when connecting to your remote SSH server. X11-forwarding mechanism does not allow anyone to use the open display.However, in some cases you may need to start a graphical application like nedit or firefox in a sudo or su context. In order to achieve this, you could manually retrieve X credentials in the su/sudo context by looking up the “xauth list” for the original username and then adding them using “xauth add” to the current context.
You can also use a single (magic) command in order to achieve this!
For instance, here is a simple scenario:
- I start a SSH session to remote server “Server1” with user “john”
- In this session, I perform a “su -” command in order to become “root”
- If I run “xclock”, the following error occurs:
MobaXterm X11 proxy: Authorisation not recognised
Error: Can’t open display: localhost:10.0
Error: Can’t open display: localhost:10.0
I just have to execute the following command in order to retrieve my display and make “xclock” work:
xauth add $(xauth -f ~john/.Xauthority list|tail -1)
We hope this will help you if you need to have a working X11 display through SSH after becoming root.xauth add $(xauth -f ~john/.Xauthority list|tail -1)
Install and configure Squid proxy server on Linux
A proxy server is a computer that acts as an intermediary between a desktop computer and the internet and allows a client machine to make an indirect connection to network servers and services. There are many reasons why you might want to include a proxy server on your network:- To share internet connection on a LAN
- To speed up internet surfing
- To hide the IP address of the client computer for anonymous surfing
- To implement internet access control
- To scan outbound content
- To circumvent regional restrictions
1. Install Squid
Squid can be easily install using yum command line tool.
2. Setup Port and Start Service
Squid by default run on port 3128. If you want to start squid on different port, Edit squid configuration file and change http_port value. For example we are changing squid to run on port 8080.
Start/Restart Squid service.
3. Configure SQUID to Block Specific Website
Add below rules to block specific website before any allow all rules. Below example will block yahoo.com and www.rediff.com.
If you have a long list of domain names, Create a file /etc/squid/blockwebsites.lst and put domain names one per line and add below rule in squid configuration file.
blockwebsites.lst file content example:
4. Configure Squid to Block Specific Keyword
Add below rules to block specific website before any allow all rules. Below example will block all pages having keyword yahoo or gmail.
If you have a long list of keywords, Create a file /etc/squid/blockkeywords.lst and put keywords one per line and add below rule in squid configuration file.
blockkeywords.lst file content example:
Congratulation’s you have successfully installed and configured Squid proxy server
Finding WWN number of HBA and Scanning FC luns in linux
So How to find WWN number of HBA and scan the FC Luns in LINUX without rebooting the server?
Here is a solution to find WWN number of HBA and scan the FC Luns.
Identify the number of HBA adapters
systool -c fc_host -vNote the number of hosts available in the server. We have Two HBA here from the above example (host0 and host1).
or
ls /sys/class/fc_host
host0 host1
To get the WWNN (World Wide Node Number) of HBA or FC card in Linux
cat /sys/class/fc_host/host0/node_name
0x20000000c9538d83
cat /sys/class/fc_host/host1/node_name
0x20000000c9538dac
To get the WWPN (World Wide Port Number) of HBA or FC card in Linux
cat /sys/class/fc_host/host0/port_name0x10000000c9538d83
cat /sys/class/fc_host/host1/port_name0x10000000c9538dac
If you have more HBAs, replace "host0 or host1" with "hostN ". In most cases, System admins need to provide the WWPN to storage admins for the storage allocation.
Scan the newly added or rescan the existing LUNs in Linux
echo "1" > /sys/class/fc_host/host0/issue_lip
echo "- - -" > /sys/class/scsi_host/host0/scan
If you have more number of hosts file under the directory /sys/class/fc_host, then use the command for each hosts file by replacing the "host0".
From Redhat Linux 5.4 onwards, redhat introduced “/usr/bin/rescan-scsi-bus.sh” script to scan all the SCSI bus and update the SCSI layer to reflect new devices.
We can also use the "rescan-scsi-bus.sh" script to detect new LUNs without rebooting the server.
This script is available with sg3-utils package. So install the sg3-utils package using yum.
yum install sg3_utils
rescan-scsi-bus.sh
Now check the detected disks using fdisk command.
6 Strategies for Migrating Applications to the Cloud
Formulating a Migration Strategy
Enterprises typically begin to contemplate how to migrate an application during the second phase of the “Migration Process” — Portfolio Discovery and Planning. This is when they determine what’s in their environment, what are the interdependencies, what’s going to be easy to migrate and what’s going to be hard to migrate, and how they’ll migrate each application.
Using this knowledge, organizations can outline a plan (which should be considered subject to change as they progress through their migration and learn) on how they’ll approach migrating each of the applications in their portfolio and in what order.
The complexity of migrating existing applications varies, depending on the architecture and existing licensing arrangements. If I think about the universe of applications to migrate on a spectrum of complexity, I’d put a virtualized, service-oriented architecture on the low-complexity end of the spectrum, and a monolithic mainframe at the high-complexity end of the spectrum.
I suggest starting with something on the low-complexity end of the spectrum for the obvious reason that it will be easier to complete — which will give you some immediate positive reinforcement or “quick wins” as you learn.
6 Application Migration Strategies: “The 6 R’s”
The 6 most common application migration strategies we see are:
1. Rehosting — Otherwise known as “lift-and-shift.”
We find that many early cloud projects gravitate toward net new development using cloud-native capabilities, but in a large legacy migration scenario where the organization is looking to scale its migration quickly to meet a business case, we find that the majority of applications are rehosted. GE Oil & Gas, for instance, found that, even without implementing any cloud optimizations, it could save roughly 30 percent of its costs by rehosting.
Most rehosting can be automated with tools (e.g. AWS VM Import/Export, Racemi), although some customers prefer to do this manually as they learn how to apply their legacy systems to the new cloud platform.
We’ve also found that applications are easier to optimize/re-architect once they’re already running in the cloud. Partly because your organization will have developed better skills to do so, and partly because the hard part — migrating the application, data, and traffic — has already been done.
2. Replatforming — I sometimes call this “lift-tinker-and-shift.”
Here you might make a few cloud (or other) optimizations in order to achieve some tangible benefit, but you aren’t otherwise changing the core architecture of the application. You may be looking to reduce the amount of time you spend managing database instances by migrating to a database-as-a-service platform like Amazon Relational Database Service (Amazon RDS), or migrating your application to a fully managed platform like Amazon Elastic Beanstalk.
A large media company we work with migrated hundreds of web servers it ran on-premises to AWS, and, in the process, it moved from WebLogic (a Java application container that requires an expensive license) to Apache Tomcat, an open-source equivalent. This media company saved millions in licensing costs on top of the savings and agility it gained by migrating to AWS.
3. Repurchasing — Moving to a different product.
I most commonly see repurchasing as a move to a SaaS platform. Moving a CRM to Salesforce.com, an HR system to Workday, a CMS to Drupal, and so on.4. Refactoring / Re-architecting — Re-imagining how the application is architected and developed, typically using cloud-native features.
This is typically driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment.Are you looking to migrate from a monolithic architecture to a service-oriented (or server-less) architecture to boost agility or improve business continuity (I’ve heard stories of mainframe fan belts being ordered on e-bay)? This pattern tends to be the most expensive, but, if you have a good product-market fit, it can also be the most beneficial.
5. Retire — Get rid of.
Once you’ve discovered everything in your environment, you might ask each functional area who owns each application. We’ve found that as much as 10% (I’ve seen 20%) of an enterprise IT portfolio is no longer useful, and can simply be turned off. These savings can boost the business case, direct your team’s scarce attention to the things that people use, and lessen the surface area you have to secure.6. Retain — Usually this means “revisit” or do nothing (for now).
Maybe you’re still riding out some depreciation, aren’t ready to prioritize an application that was recently upgraded, or are otherwise not inclined to migrate some applications. You should only migrate what makes sense for the business; and, as the gravity of your portfolio changes from on-premises to the cloud, you’ll probably have fewer reasons to retain.
