Messages posted by: Ikut3

Cách đây vài năm thì mình dùng NFS để mount qua lại giữa những NODE trong cùng 1 LAMP Stack
Bây giờ mình nghĩ có nhiều giải pháp khả thi hơn, bao gồm cả Hardware (San) hay Software v.v..
Bạn tham khảo thêm ở đây
http://www.cyberciti.biz/tips/how-to-configure-apache-web-server.html

Hô hô hoá ra tay Tee không có biết dùng vi / nano :">

lxde cũng là lựa chọn không tồi nếu muốn giảm thiếu những ứng dụng không cần thiết cho môi trường server

Sao không dùng Nagios để làm việc này ?

Đã có thêm thông tin về CRIME tại

http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/
http://www.youtube.com/embed/gGPhHYyg9r4?start=0&wmode=transparent

Nếu như vậy thì bạn cứ để mọi người chạy ổn định trong 8.8.8.8 đi.
Bao giờ configure & test okie hết thì hẵng trỏ qua 192.168.111.220. Sao lại mang Client ra để test vậy ?

Bạn tham khảo 1 trường hợp tương tự nhé. Lí giải rất rõ ràng. Ngày trước mình cũng đã từng gặp chuyện này

Questions

I have a user on Windows 7 that is trying to access a local server with a DNS name of windows.cs. We have two internal DNS servers. The DHCP server assigns users the two internal DNS servers as primary and secondary and then our ISPs DNS as a tertiary DNS server.

Every now and then, the user can't access the website at windows.cs. If I ping it, it says it can't resolve the host name. I flush the DNS cache, and then when I display the dns cache it has the following:

windows.cs - Name does not exist

Yet if I use nslookup, which by default queries the primary DNS server (our internal one) and I query windows.cs, it returns the correct IP address.

So why can't Windows resolve the hostname using ping, but it can when using the nslookup tool? And how do I fix this?

Repply

It's appears from what you're saying that the request for windows.cs is going to the ISPs DNS server now and again. The nxdomain result is then probably cached by Windows' DNS client, and thus used for any retries with a web browser, ping etc. Clearing the cache (ipconfig /flushdns) should force the Windows DNS client to retry the query, but there's no guarantee it won't go to the ISP DNS server again.

The reason ping can't resolve the hostname but nslookup can is because nslookup a low level tool that bypasses the Windows DNS client. It uses whatever DNS server you tell it to (the first one by default), and does the query on the fly. You can change the DNS server it queries by typing server <host> from the nslookup prompt, where host is the IP or FQDN.

The Windows DNS client however will only do queries for entries that are not in its cache (or have expired). Otherwise it returns the cached result.

It's not immediately apparent why the Windows client is using the ISP DNS server. Perhaps it could not resolve the local server recently (due perhaps to being on another network), perhaps the local server was returning errors. Or perhaps it is not ordered correctly under Advanced TCP/IP settings > DNS.

Personally I prefer to only use local DNS server addresses on workstations (propagated by DHCP), to simplify configuration and avoid issues like this. I'd be curious to know the rationale behind setting the ISPs DNS server on desktops. I can't image their being any valid performance reasons and as far as redundancy goes two is enough on most networks (if not add a third).

Mình nghĩ chỉ cần để 1 cái dns 192.168.111.220
Sử dụng chức năng Forwarder DNS để client có thể query những domain không có trong List Zones.
Lúc này khi bạn truy cập tên miền nội bộ thì dns sẽ tìm kiếm trong các zones có trongl list.nếu không có mới Forward ra ngoài.

Thân.

Trỏ IP public chứ sao lại trỏ IP private.

Nguyên do ở nội bộ access được là nó đang chung 1 mạng. Và nó nhìn thấy cái IP private kia. Còn bên ngoài thì làm sao nó hiểu IP private kia là cái gì

Hiểu hem ?

- Cần những gì?

1. Có lẽ việc sizing hệ thống ban đầu sẽ là 1 điểm bắt buộc phải quan tâm cho bất kì một hệ thống lớn nào. Ở HVA phải có tính chịu tải cao, giảm thiểu thời gian downtime thấp nhất, người dùng truy cập trơn chu và gặp những trở ngại hạn chế ít nhất trong phạm vi có thể chấp nhận được.
(chẳng hạn việc các user bây giờ vô tình vẫn sẽ dính các rules của firewall nếu gateway không ổn định, trình duyệt đang cài cắm thêm các addons như anonymousX hay fake user agent

Về mặt hệ thống, sự vận hành của tomcat - postgresql và 1 số các application chịu trách nhiệm cân bằng tải hay caching như nginx cũng phải luôn có sự đảm bảo về mặt chất lượng
Ngoài ra, những công cụ quản trị & theo dõi cho phía người quản lí cũng phải được đảm bảo vận hành kĩ lưỡng, chạy đúng, chạy đủ. Áp dụng các giải pháp kiểm soát các luồng truy cập và phân quyền user tương tác trên hệ thống 1 cách hợp lí.

Tổng quan, HVA cần tất cả những yếu tố cơ bản để hình thành một nền tảng có chất lượng. Dưới sự quản lí và tầm nhìn rộng cho 5 & 10 ... năm nữa

Đây là những điểm HVA nên cần.

update sau :-D

Theo mình thì dùng IP tables relay từ port 80 vào 8080 . Còn Apache thì replay từ port 81 vào 8081. Lí do là sau này, nếu bạn có dùng nhiều instance Tomcat trên này thì cũng làm tương tự vậy chứ không phải thay tiếp từng port nữa. Làm thế rất dễ rối có vấn đề trong việc BIND interface.

Tuy nhiên nếu bạn muốn change thì tham khảo cái này

It should be noted here that there is one Tomcat configuration parameter that you may or may not want to change, the proxyPort parameter in the server.xml file. Since Tomcat still receives requests on port 8080 as they are relayed by the Linux Netfilter system from port 80, Tomcat may display port 8080 in the URL depending on the application's content. So if you want to change it to port 80, the proxyPort parameter would need to be added in the $CATALINA_BASE/conf/server.xml (/opt/tomcat-instance/sales.example.com/conf/server.xml). file for port 8080:

<Connector port="8080" protocol="HTTP/1.1" proxyPort="80"
connectionTimeout="20000"
wwwectPort="8443" />

After that you need to restart Tomcat to make this change effective.

Cái reverse proxy chỉ có tác dụng cache static pages, ngoài ra không có tác dụng gì nữa. Nếu reverse proxy cho một lượng lớn request ập vào mà webserver bên trong không chịu nổi thì cũng crash.

Không đúng, reverse proxy với chức năng caching thường thấy là một trong các chức năng mà nó có thể làm. Ngoài ra vẫn có thể dùng để chia tải (load balancing), kiểm soát luồng truy cập (access control), lọc các request (handle request)

@chủ topic : tu đâu mấy cái núi rồi mà giờ hỏi "khó" quá vậy anh ?

Ngành/nghề: IT phần cứng/mạng

Mô tả công việc:
- Thành thạo ngôn ngữ PHP
- Có khả năng lập trình hướng đối tượng
- HTML, CSS tốt;
- Am hiểu về Web 2.0 (AJAX, DHML, JavaScript,…)
- Chi tiết sẽ được trao đổi cụ thể khi phỏng vấn

Phần cứng mạng mà lại phải thành thạo về các ngôn ngữ lập trình ?

@Tee : Lão cần phân biệt 2 điều
1 là Phòng. phòng để server không có shell, sạch sẽ từ các hosting shared cho đến bản thân Server
2 là Chống . chống để giả sử, lỡ có lỗ hổng trong việc phòng thì Shell cũng không thể tương tác được vào server, hoặc chuyện tương tác đó là quá nhỏ.
1 số nguồn tham khảo
http://25yearsofprogramming.com/blog/2010/20100315.htm
/hvaonline/posts/list/23670.html
oswap - mod security - chroot apache - hardening webserver linux

Cứ từ từ nó mới nhừ. smilie

Regards

Bên tôi đang có nhu cầu tuyển 1 vài bạn sinh viên IT thực tập. và tôi nghĩ như lời của Chiro8x nói, không thử làm sao biết, phải làm mới biết mình đam mê và có phù hợp với nó không. Nếu chỉ là học không, nghe không thì chưa chắc đã đủ

Nếu F5.life không chê thì có thể liên hệ. Địa điểm làm việc SaiGon.
Cty qui mô 1000 - 3000 người.

Thân mến

@CINO :

Lệch múi giờ có thể dùng Emergency Code để vào. Tuy nhiên chỉ có 4 emergency code. nếu đã sử dụng rồi thì không thể sử dụng lại.

Mình nghĩ nên có 1 NTP server đồng bộ time với các thiết bị
Mình đang đọc thêm cái này.
http://www.infosec.co.uk/ExhibitorLibrary/557/WPEventsVs.Time20061023A4.pdf

Cheers,

@ cino : 1/ Chuyện Internet thì không phải các bạn thắc mắc ở topic đây mà ở các diễn đàn khác. Mình mượn lời để repply thôi.

2/ Chuyện ISMS không yêu cầu áp dụng nhưng nó có phần Password Policy với các yếu tố
Strength - Length - max age v.v... . N Factor đáp ứng được các yêu cầu trên phải không ?

Hello mọi người

Em đào mồ vụ này lên 1 tí, do em vừa triển khai cho hệ thống bên em chạy SLES 11.

1. Đặc điểm của SLES 11 là không có gói PAM-devel đi kèm, nó chỉ có ở trên phiên bản SLES-SDK, vậy nên mọi người download gói pam-devel 1.0.4 cho phiên bản pam 1.0.4 tại đây

http://demeter.uni-regensburg.de/SLE11SP1-SDK-x64/DVD1/suse/x86_64/

2. Do cơ chế của Google Authenticator dựa trên algorithm Time-based, vì vậy chú ý điện thoại của mình phải cùng time với máy chủ

3. Có 1 số bạn thắc mắc là như vậy giữa đthoai & server luôn phải được đi Internet để cập nhật các passcode, nhưng chuyện đó là sai. Nó chỉ cần 1 algorithm, đúng hơn là 1 cipher thông qua BarCode & Secret Key ngay từ lúc khởi tạo từ phía Server để giải mã tất cả các password random sau đó. Vì vậy đthoai & Server không cần thiết phải có Internet mới áp dụng được

Sau khi chơi thử, thì mình tự tin phần password policy trong điểu khoản ISMS 27001 & PCI DSS nhẹ gánh hơn rất nhiều

Cheers,

Mình nghĩ lập 1 cái web nhỏ, cho phép người dùng changepassword định kì là điều không khó.
Hiện tại bên mình cũng setup 1 cái web như thế. Tham khảo tại đây

http://technology.mattrude.com/2010/11/ldap-php-change-password-webpage/

@quanghoacmd

Trước khi bị thế này, bạn có điểu chỉnh hoặc cài cắm gì trên hệ thống không ?
Theo mình bạn kiếm 1 cái liveCD linux, cho vào để boot lên. Sau đó mount các phân vùng hiện tại vào, thực hiện rollback cấu hình cũ đối với các file đã cấu hình, hoặc unistall các ứng dụng vừa mới cài đặt xem sao

Trình tự triển khai hợp lý cũng ảnh hưởng rất lớn đến khả năng thành công của dự án. Về điểm này rất mong bạn Ikut3 có thể chia sẻ thêm kinh nghiệm khi thực hiện.

Mình không thể chép nguyên cả cái project của mình lên đây được :-D
Nhưng khái quát nó có thể chia làm 3 phần chính, không bao gồm các phần rườm rà như lên kế hoạch - đánh giá rủi do & phương pháp dự phòng & xin approve, xin tài chính

1. Nghiên cứu các giải pháp thay thế.
Team mình chia làm 2 đội. 1 đội đi lấy nhu cầu của các phòng ban và lường trước các mở rộng trong vòng 2 năm tới. 1 đội thu thập các thông tin để nghiên cứu các giải pháp có thể đáp ứng nhu cầu hiện tại và tương lai. Viết các proposal và các proccess thay thế.

2. Chuyển đổi các dịch vụ hệ thống từ M$ -> Linux
Việc cài cắm các hệ thống xem ra lại là phần dễ nhất, tuy nhiên ở giai đoạn này chú ý đến việc security trên các services, áp đặt các policy mới, cũng như giữ lại các policy cũ của cty. Đảm bảo các dịch vụ cũ vẫn được duy trì tốt cho đến khi chuyển sang hệ thống mới. Hạn chế tối thiểu thời gian downtime của hệ thống

- Xen kẽ với các implement là những buổi training cho bộ phận kĩ thuật.

3. Chuyển đổi các Users trong vùng có thể sang Linux.
Cách ly các bộ phận vẫn phải dùng M$ ra để tìm cách giải quyết sau. Mục đích của mình ở giai đoạn này là muốn giảm thiểu các rủi do còn tồn đọng từ phía các máy M$. Không ngừng educate và training cho người dùng những thay đổi mới. Theo dõi các vấn đề phát sinh và tìm cách giải quyết tạm thời

Sau khi hoàn thành được từng phase, tiếp tục kiện toàn hệ thống, training và lấy feedback từ người dùng

Regards,

@ onhamotminh

Mình cũng mong muốn hỏi thêm về hệ thống bên Huynh :
- Các client có sử dụng Hệ điều hành OSS hết không ? hay vẫn xen kẽ MS & OSS
- Người dùng các client này đại đa số là dân CNTT hay công tác lĩnh vực khác ? Và hệ thống như Huynh mô tả thì chắc k phải công ty VN chứ !!!

1. Các client bên mình đa phần sử dụng các phần mềm chuyên biệt. Có phần mềm buộc chạy Windows, có phần mềm thì linh động cho cả 2. Tuy nhiên có 1 bước rất quan trọng trong quá trình Kick off Project là bên phía mình đều đưa ra những nhu cầu với khách hàng để dự án có thể chạy tốt nhất. 1 trong số đó là khuyến cáo dùng các phần mềm chạy trên Linux. Bản chất khách hàng nếu họ muốn 1 dự án chạy tốt, với downtime = 0, và giá thành hợp lí thì chuyện yêu cầu này cũng không phải quá khó khăn.
Đối với Cty của bạn, mình không rõ lắm là hoạt động lĩnh vực gì, có chuyên biệt quá như các cty thiết kế bắt buộc phải dùng Photoshop - AutoCad v.v.. hay không, nhưng nếu dính vào các phần mềm này thì theo mình có thể sử dụng các giải pháp ảo hoá, hoặc deal với bên supplier để có giá net, tiết kiệm chi phí.a
Đối với Cty sử dụng các phần mềm cơ bản như office là chủ yếu thì sẽ rất dễ dàng cho việc chuyển đổi. LibreOffice hay Openoffice là 1 lựa chọn không tồi. Ở cty mình, tất cả phòng ban đều sử dụng 2 sản phẩm này, file thì luôn lưu ở định dạng PDF. Vì sao Users chấp nhận điều này thì ở dưới mình sẽ trả lời.
Suy cho cùng, việc tận dụng OSS ở cty cũng chỉ ở mức tối đa, chứ không thể thay thế hoàn toàn.

2. Người dùng các client này đại đa số là dân CNTT hay công tác lĩnh vực khác ? Và hệ thống như Huynh mô tả thì chắc k phải công ty VN chứ !!!

Câu này của bạn theo mình là rất thông minh :-D. Client ở mình có 2 dạng. 1 dạng không biết gì, và 1 dạng rất biết gì. Đối với dạng không am hiểu CNTT thì đơn giản mình thường tổ chức những lớp trainning Linux và các Application Opensource để họ có thêm kiến thức khi sử dụng. 1 tờ giấy trắng bao giờ cũng dễ viết lách thêm thắt hơn 1 tờ giấy đã có chi chít chữ smilie

Dạng còn lại thì khá tốt về CNTT, vì vậy khi training về linux cũng có phần hơi thừa thãi. Không tránh khỏi những khi gặp những câu hỏi khó của họ, cũng vất vả để giải thích để hướng họ đi theo chính sách của cty. Nhưng đôi lúc vẫn phải áp đặt (force), 1 số trường hợp rất khó để giải thích cặn kẽ, rất khó để truyền đạt hết tầm nhìn của những người làm công nghệ cho họ. Đối với mình thì bao giờ các vấn đề của Client gặp phải cũng là khó khăn hơn rất nhiều những vấn đề kĩ thuật.

Đúng như bạn nói, cty mình không phải ở VN, nó trực thuộc 1 tập đoàn lớn ở nước ngoài. Tuy nhiên, như 1 bản sắc trước giờ của Board Manager, mọi người đều khuyến cáo sử dụng linux, và cảm thấy không quá khó khăn khi sử dụng nó. Dần dần khi mọi thứ đã quen rồi, họ sẽ cảm thấy thoải mái và happy hơn

Chẳng lẽ không có cty nào ở Việt Nam có thể tư vấn & triển khai việc này ta ? Hay có khó khăn gì khác mà các cty OSS không làm dịch vụ này

Như mình và mọi người đã nói ở trên. Việc chuyển giao và áp dụng OpenSource vào doanh nghiệp không phải là 1 gói sản phẩm mà nó là qui trình, là sự kết nối và thống nhất từ nhiều phòng ban xuyên suốt từ lãnh đạo đến nhân viên trong tổ chức, và kĩ thuật không phải là tất cả. Thế nên theo mình đánh giá, có lẽ do độ phức tạp của nó có tính lâu dài nên ít cty có dịch vụ này, thay vào đó họ chia nhỏ ra từng gói dịch vụ như tư vấn - triển khai - đào tạo để có thể linh động hơn. Dựa vào từng nhu cầu nhất định mà xây dựng từng việc 1 sẽ tốt hơn là dàn trải mà không có sự kết dính.

Regards,

@onhamotminh

hello, chờ mãi mới thấy repply tiếp 1 chủ đề hay thế này. Nếu có gì khó khăn thì tiếp tục hỏi chứ đừng bỏ dở giữa chừng nhé
Mình sẽ giải quyết từng vấn đề bạn đang thắc mắc, tuy nhiên cho mình hỏi hơi cá nhân tí là bạn đang ở người làm kĩ thuật hay người quản lí kĩ thuật ? Vì mình đọc xong câu này thì hơi chột dạ

Mình cũng chưa bao giờ triển khai hệ thống Open Source, nên rất mong muốn ACE nào có khả năng cung cấp dịch vụ tư vấn & triển khai hỗ trợ giúp

Theo mình, ở mỗi góc độ vị trí sẽ có những cách tiếp cận vấn đề khác nhau. Ở đây nếu bạn muốn overview các vấn đề sẽ gặp phải và cách giải quyết ở mức tương đối thì mình và mọi người sẽ tư vấn. Còn các phần quá chi tiết về kĩ thuật, thì bạn có thể search thêm các bài viết chuyên về kĩ thuật tại HVA nhé

1

Đúng là chổ này Mình đang quan tâm, các ứng dụng trên Open Source sẽ không tương thích hết với các ứng dụng đang chạy trên win. Nếu có 1 số ứng dụng không tương thích thì có phương án khắc phục như thế nào?

Trước hết phải define ra, phần mềm đó là gì, phục vụ cho nhu cầu mục đích ra sao. Đánh giá rủi do nếu chuyển qua Linux và giữ lại Windows. Tuy nhiên mình thấy các phần mềm chạy trên Windows giờ cũng hỗ trợ Linux khá nhiều. Đơn cử là cái playonlinux của Ubuntu cũng giải quyết được kha khá vấn đề. Mình có 1 cái câu mà sếp cũ mình nói với mình lúc làm cái case này là . (Bây giờ mình vẫn chưa hiểu hết smilie

)

Khi mà sự khác biệt giữa kiến trúc Linux & Windows quá nhiều thì Web Application sẽ giải quyết triệt để khoảng cách đó.

2

+ Về phía server có thể setup : Open Source (Zentyal) làm AD, chạy Master + Slave tích hợp luôn file server

Mình chưa dùng Zentyal để làm AD bao giờ. Nhưng theo mình, bạn nên hiểu Join Domain để phục vụ mục đích gì. Chẳng hạn bên mình, các máy Client không có join gì cả, tuy nhiên mình vẫn có thể áp đặt các policy security, hoặc setup các application tuỳ thích mà không cần tốn công nhiều nhờ vào puppet hoặc chef hay đơn giản hơn như clusterssh - reporsitory local v.v... Đơn giản những cũng rất hiệu quả. Hiệu quả ở chỗ tất cả client đều chung 1 platform, mọi chỉnh sửa tương tác đểu có thể dùng chung.
Cuối cùng mục đích của AD chỉ để phục vụ nhu cầu quản lí Users thuận tiện hơn, tốn ít công sức hơn. Và những giải pháp quản lí hạ tầng trên linux có khá nhiều để phục vụ bạn làm việc đó. Vậy nên theo mình là cứ think out the box, không nhất thiết cứ phải là AD cho quản lí.

3

+ Phía client : triển khai Open Source, các ứng dụng nào k tương thích thì cài trên Server ảo hoá trên nền Open Source, sau đó người dùng cần làm chương trình nào load về client (chỉ tốn 1 bản quyền cho 1 máy ảo)

Cần kiểm tra lại thật kĩ cái đoạn màu in đậm nhé, vì mỗi sản phẩm có 1 cơ chế kiểm soát bản quyền khác nhau. Tuy nhiên nếu đi về hướng ảo hoá thì cũng không phải là không có với các đại gia như Citrix - VMWare (tốn $)

Mình cũng chưa bao giờ triển khai hệ thống Open Source, nên rất mong muốn ACE nào có khả năng cung cấp dịch vụ tư vấn & triển khai hỗ trợ giúp. Mục tiêu cuối cùng đảm bảo việc hợp thức hoá việc bản quyền phần mềm, chi phí đầu tư hợp lý, đảm bảo hệ thống không gặp nhiều rủi rỏ khi chuyển đổi. Hoặc giải phảp nào khác tối ưu hơn nhờ Anh Chị Em vào thảo luận giúp

Ai cũng mong muốn như bạn trên cương vị là người quản trị hệ thống cả, nhưng đừng cố chăm chăm vào nó mà làm nặng thêm cho bản thân. Coi IT như 1 phương tiện để phục vụ doanh nghiệp, mang lại giá trị cho doanh nghiệp đó. Chứ đừng coi IT như 1 chàng GURU có khả năng làm những điều kì diệu ngoài tưởng tượng

9 điều này kết hợp với 9 điều răn của Phật thì sẽ thành người thế nào nhỉ

Thì sẽ là thầy của muôn vàn trò, nhưng thầy cũng chỉ là thầy mà thôi

Nhu cầu của mi đến đâu ? Kinh tế ở mức nào có thể chấp nhận được ?. Application sử dụng để connect vào 2 cái RDBMS này như thế nào ?
Còn về so sánh thì tao nghĩ mày search vài vòng là ra chục bảng comparison về mấy cái features kia mà

Theo mình, việc design 1 hệ thống từ ban đầu với lối đi M$ hay OpenSource là điều rất quan trọng. Chuyện chuyển sang OpenSource sẽ còn khá nhiều hệ luỵ, như chọn distro nào cho server, distro nào cho client. v.v... Rất nhiều vấn đề phát sinh khi chuyển đổi hệ thống. Cho dù bạn có tính toán hay lường trước cái rủi do đến mấy thì nó vẫn có thể xảy ra. Coi nó giống như là 1 tiến trình hơn là 1 sản phẩm

Nhìn vào bức tranh tổng thể của bạn, mình nghĩ sẽ đơn giản hơn nếu bạn chia nhỏ lẻ các phần. Tạm gọi ở đây như 1 cái Strategies với nhiều Milestone khác nhau

1. Chuyển đổi System Infrastructure từ M$ -> Linux

Vd :
Active Directory -> eDirectory (Suse Novell)
DNS -> Bind
Backup Server -> Bacula
Chú ý Ldap + Samba để tích hợp vào luôn

2. Software Standard list từ các phòng ban.

Ở giai đoạn này, bạn phải thu thập các software thường dùng của mọi người. Từ đây nghiên cứu xem nếu chuyển sang opensource có thích ứng không, có đáp ứng nhu cầu và tâm lí người dùng không. Những điều này thật ra rất quan trọng

Vd bài toán giữa

GIMP vs Photoshop ?
Ms Office vs Libre Office ?

Tuy nhiên, ở điểm này phải chú ý. Có 1 số chương trình chuyên dụng như của phòng Finance chẳng hạn, có chạy được trên linux không ? Nếu chạy được thì có bị hạn chế hay rủi do gì ?

3. Educate cho người dùng.

Đây là khâu khó nhất, và cũng là vất vả nhất cho người làm kĩ thuật. Bạn phải tôn trọng tinh thần và thói quen của người dùng. Vì Linux không phải là Windows, những bỡ ngỡ ban đầu có thể làm người sử dụng khó chịu và từ bỏ. Cho dù việc bạn tích hợp và chuyển đổi hệ thống ở 2 bước đầu tốt đến mấy mà tâm lí của Users đã không chấp nhận thì cũng coi như muối bỏ bể.
Trong trường hợp này, mình nghĩ phải có 1 tí force vào đây.

traunui wrote:

Open source thì ko tính đến kinh phí rồi nhưng time thì tuỳ khả năng thôi bác.

Mình cũng nghĩ đây là 1 tâm lí nên hạn chế, bởi vì opensource không có nghĩa là miễn phí. Cũng không nên mang suy nghĩ chuyển qua Opensource để hạn chế tiền bac, mà thực ra ở đây là phân bổ tài chính hợp lí hơn. Có những thứ của Linux sử dụng rất tốt mà người dùng không phải tốn bất kì khoản phí nào. Nhưng cũng có những thứ, nhất định phải bỏ tiền để đổi lấy ổn định và support từ phía Cty cung cấp: như các bản Linux Enterprise. Chưa kể đến các phí maintance và đội ngũ kĩ thuật phải có sự am hiểu tuyệt đối các vấn đề trên opensource có thể sẽ gặp phải.

Trên đây là 1 vài kinh nghiệm mà mình đã từng trải qua 1 năm trước cho Cty với 2000 user. Server hơn 100 con :-D

Nếu có thể giúp được gì, thì cứ phản hồi. Mình sẽ tư vấn giúp bạn