Home Home > Server
Sign up | Login

Archive for the ‘Server’ Category

« Older Entries
Newer Entries »

Oxygenise your Apache

January 24th, 2011 by

I have updated apache2-icons-oxygen with icons from KDE 4.6 RC2. Thanks Nuno & Co! Now Apache’s directory listings look a bit better ;-)

See it in action here. If you want to download the tarball/rpm, go to the Build Service.

Posted in Apache, Artwork, KDE | 1 Comment »

Make vmware workstation 7.1.3 running with opensuse 11.4 (kernel 2.6.37)

November 15th, 2010 by

Note about the 2.6.37xx

There’s a solution to make the kernel modules building under openSUSE factory (11.4) and the kernel 2.6.37

Preparation

download the lastest vmware workstation 7.1.3 (the patch is only for this version)
download the patch vmware-7.1.3-2.6.37-rc5.patch
download the script to patch patch-modules_v62-opensuse.sh

Install

Proceed to the normal installation of workstation, if you have older version, it will be replaced
by running under root account

sh VMware-Workstation-Full-7.1.3-324285.x86_64.bundle

Patch

Now we have to apply the needed patch, just run as root 

sh patch-modules_v62-opensuse.sh

Here the output result

sh patch-modules_v62-opensuse.sh 
(Stripping trailing CRs from patch.)
patching file vmci-only/include/compat_semaphore.h
(Stripping trailing CRs from patch.)
patching file vmmon-only/linux/driver.c
(Stripping trailing CRs from patch.)
patching file vmnet-only/compat_semaphore.h
(Stripping trailing CRs from patch.)
patching file vsock-only/shared/compat_semaphore.h
Stopping VMware services:
   VMware USB Arbitrator                                               done
   VM communication interface socket family                            done
   Virtual machine communication interface                             done
   Virtual machine monitor                                             done
   Blocking file system                                                done
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/2.6.37-rc5-12-desktop/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C ../../../linux-2.6.37-rc5-12 O=/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop/. modules
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/driver.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/iommu.o
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: In function ‘IOMMUUnregisterDeviceInt’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:217:17: warning: ignoring return value of ‘device_attach’, declared with attribute warn_unused_result
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/hostif.o
/tmp/vmware-root/modules/vmmon-only/linux/hostif.c: In function ‘HostIFReadUptimeWork’:
/tmp/vmware-root/modules/vmmon-only/linux/hostif.c:2004:37: warning: ‘newUpBase’ may be used uninitialized in this function
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/driverLog.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/memtrack.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/vmx86.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/cpuid.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/task.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/hashFunc.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/comport.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/common/phystrack.o
  CC [M]  /tmp/vmware-root/modules/vmmon-only/vmcore/moduleloop.o
  LD [M]  /tmp/vmware-root/modules/vmmon-only/vmmon.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/vmware-root/modules/vmmon-only/vmmon.mod.o
  LD [M]  /tmp/vmware-root/modules/vmmon-only/vmmon.ko
make[1]: Leaving directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C $PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/vmware-root/modules/vmmon-only'
cp -f vmmon.ko ./../vmmon.o
make: Leaving directory `/tmp/vmware-root/modules/vmmon-only'
Built vmmon module
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmnet-only'
make -C /lib/modules/2.6.37-rc5-12-desktop/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C ../../../linux-2.6.37-rc5-12 O=/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop/. modules
  CC [M]  /tmp/vmware-root/modules/vmnet-only/driver.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/hub.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/userif.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/netif.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/bridge.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/filter.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/procfs.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/smac_compat.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/smac.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/vnetEvent.o
  CC [M]  /tmp/vmware-root/modules/vmnet-only/vnetUserListener.o
  LD [M]  /tmp/vmware-root/modules/vmnet-only/vmnet.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/vmware-root/modules/vmnet-only/vmnet.mod.o
  LD [M]  /tmp/vmware-root/modules/vmnet-only/vmnet.ko
make[1]: Leaving directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C $PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/vmware-root/modules/vmnet-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/vmware-root/modules/vmnet-only'
cp -f vmnet.ko ./../vmnet.o
make: Leaving directory `/tmp/vmware-root/modules/vmnet-only'
Built vmnet module
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmblock-only'
make -C /lib/modules/2.6.37-rc5-12-desktop/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C ../../../linux-2.6.37-rc5-12 O=/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop/. modules
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/filesystem.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dentry.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/stubs.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dbllnklst.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/file.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/block.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/module.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/super.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/inode.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/control.o
  LD [M]  /tmp/vmware-root/modules/vmblock-only/vmblock.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/vmware-root/modules/vmblock-only/vmblock.mod.o
  LD [M]  /tmp/vmware-root/modules/vmblock-only/vmblock.ko
make[1]: Leaving directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C $PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/vmware-root/modules/vmblock-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/vmware-root/modules/vmblock-only'
cp -f vmblock.ko ./../vmblock.o
make: Leaving directory `/tmp/vmware-root/modules/vmblock-only'
Built vmblock module
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmci-only'
make -C /lib/modules/2.6.37-rc5-12-desktop/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C ../../../linux-2.6.37-rc5-12 O=/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop/. modules
  CC [M]  /tmp/vmware-root/modules/vmci-only/linux/driver.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/linux/driverLog.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/linux/vmciKernelIf.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciDatagram.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciDriver.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciDs.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciContext.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciHashtable.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciEvent.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciQueuePair.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciGroup.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciResource.o
  CC [M]  /tmp/vmware-root/modules/vmci-only/common/vmciProcess.o
  LD [M]  /tmp/vmware-root/modules/vmci-only/vmci.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/vmware-root/modules/vmci-only/vmci.mod.o
  LD [M]  /tmp/vmware-root/modules/vmci-only/vmci.ko
make[1]: Leaving directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C $PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/vmware-root/modules/vmci-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/vmware-root/modules/vmci-only'
cp -f vmci.ko ./../vmci.o
make: Leaving directory `/tmp/vmware-root/modules/vmci-only'
Built vmci module
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vsock-only'
make -C /lib/modules/2.6.37-rc5-12-desktop/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C ../../../linux-2.6.37-rc5-12 O=/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop/. modules
  CC [M]  /tmp/vmware-root/modules/vsock-only/linux/af_vsock.o
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c: In function ‘VSockVmciStreamConnect’:
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3172:4: warning: case value ‘255’ not in enumerated type ‘socket_state’
  CC [M]  /tmp/vmware-root/modules/vsock-only/linux/vsockAddr.o
  CC [M]  /tmp/vmware-root/modules/vsock-only/linux/util.o
  CC [M]  /tmp/vmware-root/modules/vsock-only/linux/stats.o
  CC [M]  /tmp/vmware-root/modules/vsock-only/linux/notify.o
  CC [M]  /tmp/vmware-root/modules/vsock-only/driverLog.o
  LD [M]  /tmp/vmware-root/modules/vsock-only/vsock.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/vmware-root/modules/vsock-only/vsock.mod.o
  LD [M]  /tmp/vmware-root/modules/vsock-only/vsock.ko
make[1]: Leaving directory `/usr/src/linux-2.6.37-rc5-12-obj/x86_64/desktop'
make -C $PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/vmware-root/modules/vsock-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/vmware-root/modules/vsock-only'
cp -f vsock.ko ./../vsock.o
make: Leaving directory `/tmp/vmware-root/modules/vsock-only'
Built vsock module
Starting VMware services:
   VMware USB Arbitrator                                               done
   Virtual machine monitor                                             done
   Virtual machine communication interface                             done
   VM communication interface socket family                            done
   Blocking file system                                                done
   Virtual ethernet                                                    done
   Shared Memory Available                                             done


All done, you can now run VMWare WorkStation.
Modules sources backup can be found in the '/usr/lib/vmware/modules/source-workstation7.1.3-2010-12-13-19:07:07-backup' directory

References

vmware community post
vmware community thread

Mark D Bernstein aka InitiaZero for providing the script and patch by email and having ping me about it

Enjoy, and thanks to people having done the crappy job before.

Tags: , , , ,
Posted in Base System, Kernel, Virtualization | 4 Comments »

OPENSUSE 11.3/SLES 11 ** INTEGRATING FREERADIUS TO LDAP SERVER

November 12th, 2010 by

FreeRADIUS is a modular, high performance free RADIUS suite developed and distributed under the GNU General Public License, version 2, and is free for download and use. The FreeRADIUS Suite includes a RADIUS server, a BSD-licensed RADIUS client library, a PAM library, anApache module, and numerous additional RADIUS related utilities and development libraries (wikipedia)

Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for computers to connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc., in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards(wikipedia)

Well, then again a bit of introduction about “what is RADIUS ?” and the FreeRADIUS, the most popular OpenSource RADIUS Server :D .

This tutorial based on an existing LDAP Server Configuration ( you can read this post) and it already has 1-2 users on it ( you can read this post again :) ),  and this post is explain how-to integrate FreeRADIUS to read and use existing user on LDAP Server.

you can install the FreeRadius server on the same server or on a seperate server ( it’s your choice :p )

  • Add the FreeRADIUS repository from software.opensuse.org
# zypper ar http://download.opensuse.org/repositories/network:/aaa/SLE_11/ FreeRadius
# zypper ref
  • Install the FreeRADIUS Server Package
# zypper in freeradius-server freeradius-client freeradius-server-utils
  • After Installing the FreeRADIUS Packages, edit /etc/raddb/modules/ldap file, and then find and edit following lines (in my case : dc=malayin,dc=net) :
ldap {

server = “192.168.0.30″ – the LDAP Server
#identity = “cn=Adminstrator,dc=malayin,dc=net”
#password = admin
basedn = “dc=malayin,dc=net” – The Base DN LDAP Server
#filter = “(uid=%{Stripped-User-Name:-%{User-Name}})”
filter = “(uid=%u)”
#base_filter = “(objectclass=radiusprofile)”
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1

tls {
start_tls = no
}
access_attr = “uid”
edir_account_policy_check = yes
}
  • After editing the ldap file, save it and then edit /etc/raddb/sites-available/default. FIND THE LINES that contain LDAP word and uncomment the lines :

authorize {
#
#  The preprocess module takes care of sanitizing some bizarre
#  attributes in the request, and turning them into attributes
#  which are more standard.
#
#  It takes care of processing the ‘raddb/hints’ and the
#  ’raddb/huntgroups’ files.
#
#  It also adds the %{Client-IP-Address} attribute to the request.
#preprocess
#
#  If you want to have a log of authentication requests,
#  un-comment the following line, and the ‘detail auth_log’
#  section, above.
# auth_log
#
#  The chap module will set ‘Auth-Type := CHAP’ if we are
#  handling a CHAP request and Auth-Type has not already been set
#chap
#
#  If the users are logging in with an MS-CHAP-Challenge
#  attribute for authentication, the mschap module will find
#  the MS-CHAP-Challenge attribute, and add ‘Auth-Type := MS-CHAP’
#  to the request, which will cause the server to then use
#  the mschap module for authentication.
#mschap
#
#  If you have a Cisco SIP server authenticating against
#  FreeRADIUS, uncomment the following line, and the ‘digest’
#  line in the ‘authenticate’ section.
# digest
#
#  Look for IPASS style ‘realm/’, and if not found, look for
#  ’@realm’, and decide whether or not to proxy, based on
#  that.
# IPASS
#
#  If you are using multiple kinds of realms, you probably
#  want to set “ignore_null = yes” for all of them.
#  Otherwise, when the first style of realm doesn’t match,
#  the other styles won’t be checked.
#
#suffix
# ntdomain
#
#  This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
#  authentication.
#
#  It also sets the EAP-Type attribute in the request
#  attribute list to the EAP type from the packet.
#
#  As of 2.0, the EAP module returns “ok” in the authorize stage
#  for TTLS and PEAP.  In 1.x, it never returned “ok” here, so
#  this change is compatible with older configurations.
#
#  The example below uses module failover to avoid querying all
#  of the following modules if the EAP module returns “ok”.
#  Therefore, your LDAP and/or SQL servers will not be queried
#  for the many packets that go back and forth to set up TTLS
#  or PEAP.  The load on those servers will therefore be reduced.
#
#eap {
# ok = return
#}
#
#  Pull crypt’d passwords from /etc/passwd or /etc/shadow,
#  using the system API’s to get the password.  If you want
#  to read /etc/passwd or /etc/shadow directly, see the
#  passwd module in radiusd.conf.
#
#unix
#
#  Read the ‘users’ file
#files
#
#  Look in an SQL database.  The schema of the database
#  is meant to mirror the “users” file.
#
#  See “Authorization Queries” in sql.conf
# sql
#
#  If you are using /etc/smbpasswd, and are also doing
#  mschap authentication, the un-comment this line, and
#  configure the ‘etc_smbpasswd’ module, above.
# etc_smbpasswd
#
#  The ldap module will set Auth-Type to LDAP if it has not
#  already been set
ldap
#
#  Enforce daily limits on time spent logged in.
# daily
#
# Use the checkval module
# checkval
expiration
logintime
#
#  If no other module has claimed responsibility for
#  authentication, then try to use PAP.  This allows the
#  other modules listed above to add a “known good” password
#  to the request, and to do nothing else.  The PAP module
#  will then see that password, and use it to do PAP
#  authentication.
#
#  This module should be listed last, so that the other modules
#  get a chance to set Auth-Type for themselves.
#
#pap
#
#  If “status_server = yes”, then Status-Server messages are passed
#  through the following section, and ONLY the following section.
#  This permits you to do DB queries, for example.  If the modules
#  listed here return “fail”, then NO response is sent.
#
# Autz-Type Status-Server {
#
# }
}
#  Authentication.
#
#
#  This section lists which modules are available for authentication.
#  Note that it does NOT mean ‘try each module in order’.  It means
#  that a module from the ‘authorize’ section adds a configuration
#  attribute ‘Auth-Type := FOO’.  That authentication type is then
#  used to pick the apropriate module from the list below.
#
#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
#  will figure it out on its own, and will do the right thing.  The
#  most common side effect of erroneously setting the Auth-Type
#  attribute is that one authentication method will work, but the
#  others will not.
#
#  The common reasons to set the Auth-Type attribute by hand
#  is to either forcibly reject the user (Auth-Type := Reject),
#  or to or forcibly accept the user (Auth-Type := Accept).
#
#  Note that Auth-Type := Accept will NOT work with EAP.
#
#  Please do not put “unlang” configurations into the “authenticate”
#  section.  Put them in the “post-auth” section instead.  That’s what
#  the post-auth section is for.
#
authenticate {
#
#  PAP authentication, when a back-end database listed
#  in the ‘authorize’ section supplies a password.  The
#  password can be clear-text, or encrypted.
#Auth-Type PAP {
# pap
#}
#
#  Most people want CHAP authentication
#  A back-end database listed in the ‘authorize’ section
#  MUST supply a CLEAR TEXT password.  Encrypted passwords
#  won’t work.
#Auth-Type CHAP {
# chap
# }
#
#  MSCHAP authentication.
#Auth-Type MS-CHAP {
# mschap
#}
#
#  If you have a Cisco SIP server authenticating against
#  FreeRADIUS, uncomment the following line, and the ‘digest’
#  line in the ‘authorize’ section.
# digest
#
#  Pluggable Authentication Modules.
# pam
#
#  See ‘man getpwent’ for information on how the ‘unix’
#  module checks the users password.  Note that packets
#  containing CHAP-Password attributes CANNOT be authenticated
#  against /etc/passwd!  See the FAQ for details.
#
#unix
# Uncomment it if you want to use ldap for authentication
#
# Note that this means “check plain-text password against
# the ldap database”, which means that EAP won’t work,
# as it does not supply a plain-text password.
Auth-Type LDAP {
ldap
}
#
#  Allow EAP authentication.
# eap
}
#
#  Pre-accounting.  Decide which accounting type to use.
#
preacct {
preprocess
#
#  Ensure that we have a semi-unique identifier for every
#  request, and many NAS boxes are broken.
acct_unique
#
#  Look for IPASS-style ‘realm/’, and if not found, look for
#  ’@realm’, and decide whether or not to proxy, based on
#  that.
#
#  Accounting requests are generally proxied to the same
#  home server as authentication requests.
# IPASS
suffix
# ntdomain
#
#  Read the ‘acct_users’ file
files
}
#
#  Accounting.  Log the accounting data.
#
accounting {
#
#  Create a ‘detail’ed log of the packets.
#  Note that accounting requests which are proxied
#  are also logged in the detail file.
detail
# daily
#  Update the wtmp file
#
#  If you don’t use “radlast”, you can delete this line.
unix
#
#  For Simultaneous-Use tracking.
#
#  Due to packet losses in the network, the data here
#  may be incorrect.  There is little we can do about it.
radutmp
# sradutmp
#  Return an address to the IP Pool when we see a stop record.
# main_pool
#
#  Log traffic to an SQL database.
#
#  See “Accounting queries” in sql.conf
# sql
#
#  Instead of sending the query to the SQL server,
#  write it into a log file.
#
# sql_log
#  Cisco VoIP specific bulk accounting
# pgsql-voip
#  Filter attributes from the accounting response.
attr_filter.accounting_response
#
#  See “Autz-Type Status-Server” for how this works.
#
# Acct-Type Status-Server {
#
# }
}
#  Session database, used for checking Simultaneous-Use. Either the radutmp
#  or rlm_sql module can handle this.
#  The rlm_sql module is *much* faster
session {
radutmp
#
#  See “Simultaneous Use Checking Queries” in sql.conf
# sql
}
#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
#  Get an address from the IP Pool.
# main_pool
#
#  If you want to have a log of authentication replies,
#  un-comment the following line, and the ‘detail reply_log’
#  section, above.
# reply_log
#
#  After authenticating the user, do another SQL query.
#
#  See “Authentication Logging Queries” in sql.conf
# sql
#
#  Instead of sending the query to the SQL server,
#  write it into a log file.
#
# sql_log
#
#  Un-comment the following if you have set
#  ’edir_account_policy_check = yes’ in the ldap module sub-section of
#  the ‘modules’ section.
#
ldap
#exec
#
#  Access-Reject packets are sent through the REJECT sub-section of the
#  post-auth section.
#
#  Add the ldap module name (or instance) if you have set
#  ’edir_account_policy_check = yes’ in the ldap module configuration
#
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
  • save the file, then add these line to /etc/raddb/clients.conf filem to decide which network is ALLOWED to use and access FreeRADIUS service (in my case : 192.168.0.0/24)  :

client 192.168.0.0/24 {

secret = testing123-1

shortname = testing123-1

}

  • After finish editing clients.conf file, save it and then test the connectivity by using radtest command

You can see detail http://www.malayin.net

Posted in Server | Comments Off

Merging SVN Repositories Explained

October 30th, 2010 by

Adding files to a SVN server is usually a task done in seconds. However, having several independent SVN repositories and wanting to “combine” them, this is not trivial—especially if you want to preserve the history.

The doc team had had three different, independent repositories on BerliOS (opensuse-ha-doc, opensuse-docmaker, and opensuse-lfl) all holding separate information. This was a bit silly, so my task was to consolidate them into opensuse-doc by keeping all history.

(more…)

Tags: , , ,
Posted in Documentation, Server, Systems Management | Comments Off

OBS 2.1: Status of SuperH (sh4) support with QEMU

October 24th, 2010 by

With established ARM support in OBS the as well as emulated MIPS and PowerPC is getting more mature, the last big embedded architecture not working in OBS with QEMU user mode was SH4. QEMU developers community had done a lot of work in improving QEMU user mode during the last months, so I can proudly present with currently only a few patches to QEMU git master OBS builds working with the SH4 port of Debian Sid. The new QEMU 0.13 released recently is a big milestone for this.

Another news is that I had fixed the bugs in Virtual Machine builds (build script) when using them with some architectures like PowerPC 32bit and SH4. So now also the combination of using for example KVM (XEN should also work) in a worker together with ARM, MIPS, PowerPC and SH4 is working. The appropriate fixes are in one of the next build script releases (if not even released already now with OBS 2.1, I have to check that). You can select architecture “sh4″ with OBS 2.1 and also start a scheduler with “sh4″.

With the use of the QEMU User Mode, you can build also accelerated native cross toolchains for your host architecture so time critical parts like the compiler can run without the emulator. This works with .deb as well as with .rpm based backages. The MeeGo Project as well as the openSUSE Port to ARM uses this technique to provide an optimum between compatibility and performance. It means you can mix natively build packages and use cross toolchains on it. The “CBinstall:” feature helps you to use native or cross builds automatically depending on if your build host is a native machine or a x86 machine with cross build. In summary, we have the current classics of linux embedded archs together now in OBS: ARM, x86, MIPS 32, PowerPC 32 and SH4.

I have uploaded the fixed QEMU package to the OBS project openSUSE:Tools:Unstable inside the package “qemu-devel” after some more testing. I have of course also a OBS meta prjconf file working with Debian Sid. The SH4 port of Debian Sid you can find at Debian Ports Site.

And last but not least I would like to thank Riku Voipio of the Debian Project, QEMU project and MeeGo project and other major contributors during the QEMU 0.13 development cycle for the restless work on QEMU user mode improvements. In case of KVM, QEMU is used even twice, with QEMU-KVM as well as QEMU User Mode. I am sure I had forgotten other important people, so thanks to them also.

Posted in Build Service, Distribution, Packaging, Toolchain, Virtualization | 3 Comments »

Matryoshka

October 20th, 2010 by

A matryoshka doll, also known as a Russian nesting doll or a babushka doll, is a set of dolls of decreasing sizes placed one inside the other. A set of matryoshkas consists of a wooden figure which separates, top from bottom, to reveal a smaller figure of the same sort inside, which has, in turn, another figure inside of it, and so on. Matryoshka Doll

Virtualization is a concept similar to the Matryoshka analogy. There is another system running inside the host machine. So it is box in a box. There are many virtualization techniques available at the disposal of the user; vmware, virtualbox, xen to name a few which requires lots of resources. Another alternative which is OpenVZ , container-based virtualization for Linux. Each container performs and executes exactly like a stand-alone server; a container can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files.

Here is a quote from TechRepublic Blog :

In the past we have looked at using OpenVZ for container virtualization on Linux. OpenVZ is great as it allows you to run compartmentalized “servers” within an operating system so you can separate systems, much like running virtual machines on a host system. With OpenVZ, you can get the benefits of virtualization without the overhead.

The downside of OpenVZ is that it isn’t in the mainline kernel. This means you need to run a kernel provided by the OpenVZ project. By itself this isn’t necessarily a problem, unless you are running an unsupported Linux distribution, and also if you don’t mind a bit of lag from upstream security fixes

So what is an alternative; well maybe lxc is the answer.According to http://lxc.sourceforge.net/

The  container  technology  is actively being pushed into the mainstream linux kernel. It provides the resource management through the control groups aka process containers and resource isolation through the namespaces.

There is very little information regarding LXC in the opensuse wiki and the only one available is still draft, yet provides enough information to start rolling up your containers.  Here is the preamble of the above mentioned page:

LXC is a form of paravirtualization. Being a sort of super duper chroot jail, it is limited to running linux binaries, but offers essentially native perfomance as if those binaries were running as normal processes right in the host kernel. Which in fact, they are.

LXC is interesting primarily in that:

  • It can be used to run a mere application, service, or a full operating system.
  • It offers essentially native performance. A binary running as an LXC guest is actually running as a normal process directly in the host os kernel just like any other process. In particular this means that cpu and i/o scheduling are a lot more fair and tunable, and you get native disk i/o performance which you can not have with real virtualization (even Xen, even in paravirt mode) This means you can containerize disk i/o heavy database apps. It also means that you can only run binaries that the host kernel can execute. (ie: you can run Linux binaries, not another OS like Solaris or Windows)

The same page also states there is not another HOWTO or documentation explaining how to use lxc with opensuse even though the lxc package has been part of the main oss repo since 11.2 version. Furthermore there are no scripts like lxc-fedora or lxc-debian  that will automate the creation or installation of opensuse. Now while it may be true that there are no opensuse specific scripts are available (at least I could not find through a Google search), though there is an interesting video on youtube showing the lxc with opensuse 11.2.

Based on the the information on the LXC wiki page, using the  SUSEStudio , I built an appliance which  is almost ready to use lxc. In order to create a container image, a very primitive lxc_opensuse script that will do a fairly basic job is also included. Once the script is issued,it will download opensuse 11.3 base system and the user can start playing with the wonders of lxc. For the impatient, who wants do discover Matryoshka, here is the link for  the appliance .

Have fun with Matryoshka !

Tags: , , ,
Posted in Virtualization | 1 Comment »

On-Access virus scanning on openSUSE 11.3

September 14th, 2010 by

One of the most useful deployment scenario for Linux in enterprise or educational environment is a fileserver with on access virus scanning, to serve Windows PCs on the network of course. Long ago there used to be samba-vscan that worked very nicely, it went missing in openSUSE 11.2 so dazuko kernel module worked in its place. On 11.3 dazuko is no longer available, enter dazukofs.

(more…)

Posted in Documentation, Education, Samba, Security, Server | 4 Comments »

OBS 2.1: ACL Feature and Status

August 15th, 2010 by

One and a half year is now gone since I posted about my work for ARM support in the OBS and the work for a port of openSUSE to ARM. Lots of things had happened in the meantime that are related, from my limited view most notably Nokia and Intel joining Moblin and Maemo to MeeGo (MeeGo is currently working on a number of Atom and ARM based devices), chosing to use OBS as build system and last but not least myself joining The Linuxfoundation (you will be not surprised to hear that I work at LF on OBS). In the meantime there had also been a major new OBS release 1.8/2.0 with a bunch of new features.

Interesting is the fact that we adapted the cross build system for OBS to MeeGo, first developed for use in Maemo and openSUSE @ ARM. An improved version for the standard MeeGo releases, and for the MeeGo weekly snapshots is used in the MeeGo OBS System to build all ARM releases of MeeGo (the cross toolchain will later get part of the MeeGo SDK @ ARM), thanks to Jan-Simon Möller (In the openSUSE ML, the issue of reactivating openSUSE:Factory ARM builds were brought up. So it might be a good variant to backport Jan-Simons new solution back into openSUSE @ ARM for that purpose). All the MeeGo related OBS installations will move sooner or later to OBS 2.1.

But now to the most recent work, Access Control support. A preview was shipped with OBS 1.8. Now an own OBS version, 2.1, will be dedicated to the introduction of this single new feature into the OBS mainline: Access Control (or abbrevated ACL for Access Control Lists). ACL means that there is control by the user on a per project or per package basis to protect information, source and binaries from the read access of other users in an OBS system and to hide projects or packages.

What is the intended audience of ACL? ACL is intended for installations of OBS that require protection of projects or packages during work. This can be but is not limited to commercial installations of OBS, or semi public installations of OBS.

How does ACL work? ACL sits on top of two features introduced with OBS 2.0: Role and Permission Management as well as freely definable user groups. ACL uses 4 specifically defined permissions (‘source_access’ for read access to sources, ‘private_view’ for viewing package and project information, ‘download_binaries’ for read access to binaries and ‘access’ permission to protect and hide everything and all from read access and viewing) on a user or group in the Role and Permission management. Also, the preexisting roles “maintainer”, “reader” and “downloader” had been modified with specific predifined permissions (which can at any time changed with the role and permission editor dynamically). And last but not least 4 new flags (namely ‘sourceaccess’ to signal a project/package has read protected source code, ‘binarydownload’ to signal it has read protected packages, ‘privacy’ to signal information/logfiles or status cannot be read and ‘access’ to hide and protect a project or package completely in all possible OBS API calls) had been added to the project and package descriptions to signal that some information is only readable by specific users or groups, or that information is hidden.

How do I use ACL? There are 4 steps to use ACL (a part of them a optional and can only be performed by the Administator of an OBS instance). Step one is to assign the listed permissions to a role, user or group (this step can be done only by the admin, and is not needed for the predefined roles “maintainer”, “reader” and “downloader”). Step two is to add a group for special users to projects which are intended to be run with ACL (this operations can only be performed by the admin). Step three is to protect a project with appropriate protection flags at project creation by adding them to the project meta. Step four is to add other users or groups with one of the new predefined roles that has ACL permissions added to the project meta.

What information can be protected by ACL? The protected information is grouped into 4 categories. Category 1 (flag ‘sourceaccess’) is source code. Category 2 (flag ‘binarydownload’) is binary packages or logfiles or builds. Category 3 (flag ‘privacy’) is project or package information like build status. Category 4 (flag ‘access’) is all viewable or accessable information to any project or package (full blocking of all access and information).

Example of a project configuration using ACL:

<user userid="MartinMohring" role="maintainer" />
<!-- grant user full write and read access -->

<group groupid="MeeGo-Reviewer" role="maintainer" />
<!-- grant group full write and read access -->

<group groupid="MeeGo-Developers" role="reader" />
<!-- grant group full source read access -->

<group groupid="MeeGo-BetaTesters" role="downloader" />
<!-- grant group access to packages/images -->

  <sourceaccess>
    <disable/>
  </sourceaccess>
  <!-- disable read access - unless granted explictely.
          This flag will not accept arch or repository arguments. -->

  <binarydownload>
    <disable/>
  </binarydownload>
  <!-- disable access - unless granted explictely -
          to packages/image and logfiles -->

  <access>
    <disable/>
  </access>
  <!-- disable access - unless granted explictely-,
          project will not visible or found via search,
          nor will any source or binary or logfile be accessable.
          This flag will not accept arch or repository arguments. -->

  <privacy>
    <enable/>
  </privacy>
  <!-- project will not visible.
          This flag will not accept arch or repository arguments. -->

What is the current status of the ACL implementation? The current status is that the complete API of the OBS git master had been instrumented with ACL code, critical portions of the API controllers had been code inspected and a big portion of these API calls now have a testcase in the OBS testsuite. Work is ongoing to make ACL as secure as possible. A code drop of current git master is under test in some bigger OBS systems, most notably the openSUSE Buildsystem. You can find snapshots of this codebase as usual in the OBS project openSUSE:Tools:Unstable. Adrian Schröter updates these “Alpha Snapshots” relatively often, on a 1-2 weekly basis, and runs the testsuite on git master daily. Thanks to Jan-Simon Möller for putting in many of the testcases into the testsuite for the ACL checks. On OBS Testing in general, read also Development and Test.

What is next? Code is tested and debugged against granting unwanted access due to some concepts inside OBS that are “working against ACL”, like project or package links, aggregates or kiwi imaging. We will inform you interested user of course about beta releases and an official 2.1 release.

Stay tuned.

Posted in Build Service, Packaging, Quality Assurance, Toolchain, Virtualization | Comments Off

Local caching for CIFS network file system – followup

August 5th, 2010 by

Here’s a follow-up to my previous post on Hackweek V: Local caching for CIFS network file system

Since the previous post, I worked on improving the patches that add local caching, fixed a few bugs, addressed review comments from the community and re-posted the patches. I also gave a talk about it at the SUSE Labs Conference 2010 took place at Prague. The slides can be found here: FS-Cache aware CIFS.

This patchset was merged in the upstream Linux kernel yesterday (Yay!) which means this feature would be available starting from kernel version 2.6.35-rc1.

The primary aim of caching data on the client side is to reduce the network calls to the CIFS Server whenever possible, thereby reducing the server load as well the network load. This will indirectly improve the performance and the scalability of the CIFS Server and will improve the number of clients per Server ratio. This feature could be useful in a number of scenarios:

– Render farms in Entertainment industry – used to distribute textures to individual rendering units
– Read only multimedia workloads
– Accelerate distributed web-servers
– Web server cluster nodes serve content from the cache
– /usr distributed by a network file system – to avoid spamming Servers when there is a power outage
– Caching Server with SSDs reexporting netfs data
– where a persistent cache remains across reboots is useful

However, be warned that local caching may not suitable for all workloads and a few workloads could suffer a slight performance hit (for e.g. read-once type workloads). So, you need to careful consider your workload/scenario before you start using local disk caching.

When I reposted this patchset, I got asked whether I have done any benchmarking and could share the performance numbers. Here are the results from a 100Mb/s network:

Environment
————

I’m using my T60p laptop as the CIFS server (running Samba) and one of my test machines as CIFS client, connected over an ethernet of reported speed 1000 Mb/s. ethtool was used to throttle the speed to 100 Mb/s. The TCP bandwidth as seen by a pair of netcats between the client and the server is about 89.555 Mb/s.

Client has a 2.8 GHz Pentium D CPU with 2GB RAM
Server has a 2.33GHz Core2 CPU (T7600) with 2GB RAM

Test
—–
The benchmark involves pulling a 200 MB file over CIFS to the client using cat to /dev/zero under `time’. The wall clock time reported was recorded.

First, the test was run on the server twice and the second result was recorded (noted as Server below i.e. time taken by the Server when file is loaded on the RAM).
Secondly, the client was rebooted and the test was run with caching disabled (noted as None below).
Next, the client was rebooted, the cache contents (if any) were erased with mkfs.ext3 and test was run again with cachefilesd running (noted as COLD)
Next the client was rebooted, tests were run with caching enabled this time with a populated disk cache (noted as HOT).
Finally, the test was run again without unmounting or rebooting to ensure pagecache remains valid (noted as PGCACHE).

The benchmark was repeated twice:

Cache (state) Run #1 Run#2
============= ======= =======
Server 0.104 s 0.107 s
None 26.042 s 26.576 s
COLD 26.703 s 26.787 s
HOT 5.115 s 5.147 s
PGCACHE 0.091 s 0.092 s

As it can be seen when the disk cache is hot, the performance is roughly 5X times than reading over the network. And, it has to be noted that the Scalability improvement due to reduced network traffic cannot be seen as the test involves only a single client and the Server. The read performance with more number of clients would be more interesting as the cache can positively impact the scalability.

Tags: , ,
Posted in Hackweek, Kernel, Samba, Server | Comments Off

Happy 15th PhP

June 9th, 2010 by

Did you remember the June 8th 1995 ?
There was a annonce here

http://groups.google.com/group/comp.infosystems.www.authoring.cgi/msg/cc7d43454d64d133

Announcing the Personal Home Page Tools (PHP Tools) version 1.0.

These tools are a set of small tight cgi binaries written in C.
They perform a number of functions including:

. Logging accesses to your pages in your own private log files
. Real-time viewing of log information
. Providing a nice interface to this log information
. Displaying last access information right on your pages
. Full daily and total access counters
. Banning access to users based on their domain
. Password protecting pages based on users’ domains
. Tracking accesses ** based on users’ e-mail addresses **
. Tracking referring URL’s – HTTP_REFERER support
. Performing server-side includes without needing server support for it
. Ability to not log accesses from certain domains (ie. your own)
. Easily create and display forms
. Ability to use form information in following documents

Here is what you don’t need to use these tools:

. You do not need root access – install in your ~/public_html dir
. You do not need server-side includes enabled in your server
. You do not need access to Perl or Tcl or any other script interpreter
. You do not need access to the httpd log files

The only requirement for these tools to work is that you have
the ability to execute your own cgi programs. Ask your system
administrator if you are not sure what this means.

The tools also allow you to implement a guestbook or any other
form that needs to write information and display it to users
later in about 2 minutes.

The tools are in the public domain distributed under the GNU
Public License. Yes, that means they are free!

For a complete demonstration of these tools, point your browser
at: http://www.io.org/~rasmus

–
Rasmus Lerdorf
ras… @io.org

http://www.io.org/~rasmus

Now 15 years after, great way. And daily basis work with it. Thanks Rasmus, Thanks PhP dev’s, thanks openSUSE packagers … For those who need php applications, framework, lib and so just have a look at this long list of what is ready to use on your favorite distribution

http://packages.opensuse-community.org/index.jsp?searchTerm=php&distro=openSUSE_112

Tags: , ,
Posted in Contrib, openSUSE 11.2, Server | Comments Off

« Older Entries
Newer Entries »