Written on 3:08 下午 by Yu Lai
最近要搞在Mips的板子上搞Embedded Linux，
要透過網路開機來啟動，所以有了幾下的研究。
其概念為client開機時透過網卡的設定呼叫dhcp或bootp取得ip，
並向server以tftp的方式將boot image檔載入執行開機的動作。
在FreeBSD/Linux上可以透過網路開機，
設定的方法依照機器的網路卡功能的支援不同而有所不一樣。
以下是常見的幾種方式和設定方法：
(PS: 以下設定以Linux為主，FreeBSD則會有些許的不同。)
1. rboot
先介紹rboot
1.1 取得rbootd
如果你的網卡支援rboot開機的話，你必須有台Server來負
責handle boot request，所以首先你必須安裝rbootd。
1.2 設定rbootd
安裝完rbootd後需設定rbootd.conf來設定rbootd。
一般而言rbootd會位於/etc/rbootd.conf
設定範例如下:
# ethernet addr boot file comments
08:00:09:87:e4:8f lifimage_715 # PA/Linux kernel for 715/33
08:00:09:70:04:b6 lifimage_720 # PA/Linux kernel for 720
1.3 安裝boot file
將在rbootd.conf裡設定的boot file置於rbootd的目錄，一般是/var/lib/rbootd。
2. dhcp/tftp
這是最常見的一種方式，也是目前主流的diskless system建置的方法。
2.1 取得dhcp/tftp
先透過rpm或apt-get等方式來安裝server必要的檔案。
rpm: dhcp tftpd
(FreeBSD可以用Ports安裝/usr/ports/net/isc-dhcp3-server即可)
2.2 設定dhcp/tftp
1.修改/etc/inetd.conf或/etc/xinetd.d/tftp
inetd.conf中加入:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot
xinetd.d/tftp:
service tftp
{
disable = no //yes改成no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -s /tftpboot //加上-c參數
per_source = 11
cps = 100 2
flags = IPv4
}
改完後接著重新啟動inetd或xined。
(FreeBSD則是改/etc/inetd.conf並在/etc/rc.conf中啟動inetd。)
這邊要注意的是我們必須將開機用的檔案放置於/tftpboot中。
2. 參考man 5 dhcpd.conf來修改dhcpd.conf，範例如下：
allow bootp;
default-lease-time 600;
max-lease-time 7200;
# This will tell the box its hostname while booting:
use-host-decl-names on;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
option domain-name "foo.com";
option domain-name-server 192.168.1.4;
}
host tatooine {
hardware ethernet 00:40:05:18:0c:dd;
fixed-address 192.168.1.22;
filename "lifimage-tatooine";
option root-path "/exports/tatooineroot";
}
3. bootp/tftp
這是和dhcp/tftp類似，主要是dhcp已經將bootp的功能包含在一起的關係。
但由於網路架構的關係(e.g. 已有dhcp server)，也是個常見的採用方式。
3.1 取得bootp/tftp
先透過rpm或apt-get等方式來安裝server必要的檔案。
rpm: bootp tftpd
(FreeBSD皆已內建其中)
3.2 設定bootp/tftp
1.修改/etc/inetd.conf或/etc/xinetd.d/tftp
inetd.conf中加入:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot
bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
xinetd.d/tftp和xinetd.d/bootps:
service tftp
{
disable = no //yes改成no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -s /tftpboot //加上-c參數
per_source = 11
cps = 100 2
flags = IPv4
}
service bootps
{
disable = no //yes改成no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/bootpd
server_args = -i -t 120
per_source = 11
cps = 100 2
flags = IPv4
}
改完後接著重新啟動inetd或xined。
(FreeBSD則是改/etc/inetd.conf並在/etc/rc.conf中啟動inetd。)
這邊要注意的是我們必須將開機用的檔案放置於/tftpboot中。
2. 參考man 5 bootptab來修改/etc/bootptab，範例如下：
vodka:hd=/tftpboot:\
:rp=/usr/src/parisc/:\
:ht=ethernet:\
:ha=080069088717:\
:ip=140.244.9.208:\
:bf=lifimage:\
:sm=255.255.255.0:\
:to=7200:
Posted in
技術,
FreeBSD,
Linux,
Network
|
Written on 10:00 上午 by Yu Lai
最近在幫Pinter弄系統，發現Tomcat偶爾會噴OutOfMemory
的Exception出來，而在Console中也沒有辦法Trace出怎麼發生的。
Survey了一下才發現，原來除了存取大量的資料外，在Tomcat中使用
Singleton Pattern會有這類問題。
原因如下：
Hard references to classes can prevent the garbage collector from reclaiming the memory allocated for them when a ClassLoader is discarded. This will occur on JSP recompilations, and webapps reloads. If these operations are common in a webapp having these kinds of problems, it will be a matter of time, until the PermGen space gets full and an Out Of Memory is thrown.
而解決方法有三種：
Workaround 1: Move the class to another classloader
This workaround is for the case this class should be shared between webapps, or if the server will contain only one webapp. That is, we need to use the same instance across several webapps in the same server, or there is no need to worry about it. In this case, the class will need to be deployed on a shared classloader. This means this class must be in the shared/lib or shared/classes directory.
This way, the class will be loaded by a parent classloader, and not by the webapp classloader itself, so no resources need to be reclaimed on webapp reloadings.
This workaround may not always fit well with your code or design. In particular, care must be taken to avoid the singleton to keep references to classes loaded through the webapp classloader, because such references would prevent the classloader from being deallocated. A servlet context listener could be used to get rid of those references before the context is destroyed.
Workaround 2: Use commons-discovery
If you need to have a singleton instance for each webapp, you could use commons-discovery. This library provides a class named DiscoverSingleton that can be used to implement singletons in your webapp.
For using it, the class to be used as singleton will need to implement an interface (SPI) with the methods to be used. The following code is an example of usage of this library:
MyClass instance = DiscoverSingleton.find(MyClass.class, MyClassImpl.class.getName());
It is important, for this library to work correctly, to not keep static references to the returned instances.
Just by using this syntax, you get the following advantages:
Any class could be used as a singleton, as long as it implements an SPI interface.
Your singleton class has been converted into a replaceable component in your webapp, so you can "plug-in" a different implementation whenever you want.
But only this does not make for a workaround. The most important advantage is the DiscoverSingleton.release() method, that releases all references to instantiated singletons in the current classloader. A call to this method could be placed into a ServletContextListener, into its contextDestroyed() method.
That is, with a ServletContextListener simple implementation like the following:
public class SingletonReleaser implements ServletContextListener {
public contextInitialized(ServletContextEvent event) { }
public contextDestroyed(ServletContextEvent event) {
DiscoverSingleton.release();
}
}
we could release all cached references to the instantiated singletons. Of course, this listener should be registered on the web.xml descriptor before any other listener that could use a singleton.
Workaround 3: Use ServletContext attributes
This refactoring will work well provided the ServletContext instance is available, as a local variable or as a parameter.
It will be more efficient than using commons-discovery, but has the disadvantage of making your code depend on the web layer (ServletContext class). Anyway, I have found out that, in some cases, it is a reasonable approach.
There are many ways to do this refactoring, so I will just present one implementation that works well for me:
Create the following ServletContextListener:
public class SingletonFactory implements ServletContextListener {
public static final String MY_CLASS = "...";
/**
* @see ServletContextListener#contextInitialized(ServletContextEvent)
*/
public void contextInitialized(ServletContextEvent event) {
ServletContext ctx = event.getServletContext();
ctx.setAttribute(MY_CLASS, new MyClass());
}
/**
* @see ServletContextListener#contextDestroyed(ServletContextEvent)
*/
public void contextDestroyed(ServletContextEvent event) {
ctx.setAttribute(MY_CLASS, null);
}
/**
* Optional method for getting the MyClass singleton instance.
*/
public static MyClass getMyClassInstance(ServletContext ctx) {
return (MyClass)ctx.getAttribute(MY_CLASS);
}
}
Register the listener in the web.xml descriptor
Replace the calls to MyClass.getInstance() by:
MyClass instance = (MyClass)ctx.getAttribute(SingletonFactory.MY_CLASS);
/* or, if implemented:
MyClass instance = SingletonFactory.getMyClassInstance(ctx);
*/
Posted in
技術,
Java
|
Written on 10:44 下午 by Yu Lai
http://www.youtube.com/watch?v=IFN_ceKOcbU&mode=related&search=
一共三集...真是太好笑了...lololol
看著南方公園的畫面..背景是阿拉希戰場的音樂...好惡搞啊...XD
還惡搞B社的員工跟老闆..自己開發的..卻都沒有遊戲角色帳號....
搶車那一段..應該是惡搞GTA系列吧...還蠻像的...cc
不過最後那一把神兵怎麼沒有靈魂綁定啊...=.=
Posted in
閒聊
|
發表文章
